Firebird a GBAK na velkou GDB
Otázka od: Tomas Hulek
15. 10. 2004 6:31
Zdravim,
chtel bych se podelit o svoji ne dobrou zkusenost se zalohovanim databaze
pomoci nastroje GBAK u Firebirdu 1.5
Mam databazi, ktera ma 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13
milionu zaznamu.
Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy chvili kdy z
te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK tuto
databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani prave teto
velke tabulky (GBAK poustim s parametrem -verbose) a nebo to zkonci s
errorem deadlock ???
Mate nekdo podobnou zkusenost a pokud mozno by mi poradil jak na to ?
Zkousel jsem poustet GBAK s parametry -garbage -ignore -limbo (pro jistotu
vsechno) a vysledek je stejnej !
Misto na disku mam a PC je P4-2,60GHz, 1GB RAM
th
Odpovedá: Petr Zahradnik
15. 10. 2004 19:24
Puvodni zprava ze dne 15.10.2004:
> Eriku, sevce, proc se radsi nedrzis sveho kopyta ? Alespon by jsi ze
> sebe nedelal verejne blazna.
Jsou vazne nutna takova slova??? Retoricka otazka - takze prosim
neodpovidat a zklidnit hormony, dekuji.
Jinak, kdyz uz na to musim koukat - "by jsi" se cesky pise "bys".
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Milan Tomes
15. 10. 2004 6:43
Tuto zkusenost mame take - mame tabulku ve ktere je cca. 1mil. zaznamu a pri
jejim vyprazdneni si na nove otevreni musime nekolik hodin pockat. Tabulka
se skutecne otevre, ale bohuzel to trva takto dlouho 
Stejne se to chova
pri gbaku. Mam za to, ze je to zpusobeno natural scanem, ktery probehne
vsechny zaznamy a rusi je, nicmene nechapu proc to trva takhle neskutecne
dlouho.
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Tomas Hulek
> Sent: Friday, October 15, 2004 7:31 AM
>
> Mam databazi, ktera ma 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13
> milionu zaznamu.
> Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy
> chvili kdy z
> te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK tuto
> databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani
Odpovedá: petr palicka
15. 10. 2004 6:53
Ahoj,
odvazim se tvrdit, ze to ma na svedomi MGA (multigeneracni
architektura). Jinymy slovy: server prochazi vsechny verze zaznamu a
odstranuje neplatne, coz mu da fakt zabrat. Tohle by mohl jisteji vedet
P.Cisar.
Nam se stalo, ze program pri stratu dela nejaky ten alter table.
Jenze zakaznik pracoval stylem: import z DOS aplikace, tisk sestavy,
prace v DOS, import z DOS... Cimz mel GDB 100MB a alter ty jedny
tabulky, ktera mela nevim kolik tisic zrusenych radku do druhyho dne
nedojel. Nastesti v tomto pripade slo smazat databazi a znovu
naimportovat data.
Peca
Odpovedá: Pavel Cisar
15. 10. 2004 8:41
Haj hou!
On 15 Oct 2004 at 7:31, Tomas Hulek wrote:
> chtel bych se podelit o svoji ne dobrou zkusenost se zalohovanim
> databaze pomoci nastroje GBAK u Firebirdu 1.5 Mam databazi, ktera ma
> 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13 milionu zaznamu.
> Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy chvili
> kdy z te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK
> tuto databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani
> prave teto velke tabulky (GBAK poustim s parametrem -verbose) a nebo
> to zkonci s errorem deadlock ???
Muze za to Multigeneracni architektura, a odstranovani "smeti".
> Zkousel jsem poustet GBAK s parametry -garbage -ignore -limbo (pro
> jistotu vsechno) a vysledek je stejnej ! Misto na disku mam a PC je
> P4-2,60GHz, 1GB RAM
Parametr -garbage_collect obvykle pomuze, ale zalezi i na dalsich
okolnostech. Tento pripad je ponekud extremni. Parametr -
garbage_collect rovnez prilis nepomaha, pokud v prubehu zalohovani s
databazi pracuje jeste nekdo dalsi.
> Mate nekdo podobnou zkusenost a pokud mozno by mi poradil jak na to ?
Pokud zrusite vetsi mnozstvi dat v databazi, doporucuje se ihned
provest sweep (pomoci gfix), a pripadnou zalohu az po sweepu. Sweep
je v takovem pripade rychlejsi. Odstraneni smeti je rovnez rychlejsi,
pokud s databazi prave nikdo dalsi nepracuje. Dalsiho zrychleni
sweepu (ale i zalohovani) lze dosahnout pouzitim verze Classic v
lokalnim pripojeni (pouze Linux, nikoliv Classic na Windows!).
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Pavel Cisar
15. 10. 2004 10:18
Haj hou!
Nejak mi to po ranu nemysli 
Zapomel jsem dodat, ze pri vymazu
(ale i pri zmene) velkeho mnozstvi dat z tabulky je nejvetsi problem
s indexy. Odstranovani smeti v podobe starych verzi radku se da jeste
prezit, pokud to neni Super Server a server je zaroven pod zatezi od
vice uzivatelu (pak muze dojit k "vyhladoveni" GC vlakna), ale v
odstraneni smeti z indexu. Proto je nanejvyse vhodne po hromadnem
vymazu nebo zmene cca 1/3 radku v tabulce ihned deaktivovat a
opetovne aktivovat indexy (u FK je nutne "zacvicit" s constraints, PK
se da vetsinou preskocit). Pri takovych operacich by s db nemel nikdo
dalsi pracovat, anzto je to bepecnejsi a predevsim mnohem rychlejsi.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Stepan Dobias
15. 10. 2004 10:40
Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
termin objasnit?
PS: K utilitam gfix a gbak pro FB1.0 bych podotknul jen tolik, ze jejich
pouziti mi pripada velmi zdlouhave (stejne velka DB na MS SQL-Serveru se pri
pouziti backupne za radove asi petinu casu nez na FB). A pouziti parametru
sweep u databaze s velikosti okolo 1,7 GB trva i desitky hodin.
Stepan
Odpovedá: petr palicka
15. 10. 2004 11:07
Stepan Dobias wrote:
> Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
> termin objasnit?
viz dbsvet.cz, kde je to pekne popsany, nebo hledej na ibphoenix.cz, ale
jsou to vsecko dost stary clanky. mozna google
peca
Odpovedá: Marek Spisak
15. 10. 2004 13:57
Stepan Dobias wrote:
>Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
>termin objasnit?
>
Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
IB/FB nepouziva zamky a transakcni protokol pro odstineni transakci. V
databazi je udrzovana historie verzi radku - od nejnovejsi k nejstarsi
tak, jak byla vytvorena jednotlivymi transakcemi. Diky teto historii
muze server pristoupit ke kterekoliv verzi radku, ktera je pro konkretni
transakci relevantni. Mezi vyhody patri velka propustnost systemu,
zvlaste u transakci s vyssi urovni izolace. Vyhodou je take moznost
zalohovat databazi za provozu. Nevyhodou je nutnost cisteni DB od
"spiny", tj. starych verzi radku.
Velice pekne je tato problematika popsana v knize Pavla Cisare Podrobna
prirucka InterBase/Firebird - Tvorba, administrace a programovani
databasi ISBN 80-7226-946-1
Marek
Odpovedá: Winsoft
15. 10. 2004 14:35
> Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
> IB/FB nepouziva zamky a transakcni protokol pro odstineni transakci. V
> databazi je udrzovana historie verzi radku - od nejnovejsi k nejstarsi
> tak, jak byla vytvorena jednotlivymi transakcemi. Diky teto historii
> muze server pristoupit ke kterekoliv verzi radku, ktera je pro konkretni
> transakci relevantni. Mezi vyhody patri velka propustnost systemu,
> zvlaste u transakci s vyssi urovni izolace. Vyhodou je take moznost
> zalohovat databazi za provozu. Nevyhodou je nutnost cisteni DB od
> "spiny", tj. starych verzi radku.
mne sa zda, ze tato architektura riesi problem, ktory by vlastne nemal
byt problemom, lebo transakcie by mali byt kratke. V praxi sa samozrejme
mozu take transakcie zist, ale stavat na nich architekturu databazoveho
servera? MS SQL 2005 bude podporovat Snapshot Isolation,
predpokladam, ze je to nieco obdobne, ak nie to iste viz.
http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
Erik
Odpovedá: Pavel Cisar
15. 10. 2004 19:00
Haj hou!
On 15 Oct 2004 at 15:35, Winsoft wrote:
> > Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
<snip>
> mne sa zda, ze tato architektura riesi problem, ktory by vlastne nemal
> byt problemom, lebo transakcie by mali byt kratke. V praxi sa samozrejme
> mozu take transakcie zist, ale stavat na nich architekturu databazoveho
> servera? MS SQL 2005 bude podporovat Snapshot Isolation,
> predpokladam, ze je to nieco obdobne, ak nie to iste viz.
> http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
Eriku, sevce, proc se radsi nedrzis sveho kopyta ? Alespon by jsi ze
sebe nedelal verejne blazna.
1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
modifikujici data jsou typicky kratke, transakce ktere data
zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
transakce provadejici zmeny potrebuji spise atomicitu operaci,
protoze transakce zpracovavajici data vyzaduji predevsim prave
stabilitu dat.
3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
striktni serializace transakci, tedy nulova paralelnost zpracovani.
Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
stastne a spokojene bezet soucasne na plne obratky, staci jedna ktera
zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do haje.
Multigeneracni architektura velice ucinne izoluje transakce ktere
pouze nebo predevsim ctou od zmen provedenych jinymi transakcemi,
takze se navzajem neblokuji (pokud se ovsem spravne nastavi parametry
transakci).
4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
*specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
starsi verze jsou v podstate ulozeny externe mimo databazi).
Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
obycejny bastl.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Winsoft
15. 10. 2004 22:57
> 1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
> modifikujici data jsou typicky kratke, transakce ktere data
> zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
> obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
a teraz zhodnotme ako tento problem riesi MGA: poskytne sice
snapshot ale za cenu nasledneho zdlhaveho zbierania narobeneho
smetia. Takze ked robim uzavierku, najprv usetrim cas a neskor ho
stratim. Aky je potom z toho celkovy efekt? Nehovoriac o tom,
ze v dosledku takejto architektury ma system automaticky vecsiu
reziu vlastne pri kazdej databazovej operacii. Mne sa zda byt
vyhodnejsie minimalizovat transakcne problemy komplexne,
nie len zobrat jeden pripad (podla mna vobec nie typicky pripad)
pouzitia a na nom vybudovat architekturu databazy.
> 2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
> stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
> transakce provadejici zmeny potrebuji spise atomicitu operaci,
> protoze transakce zpracovavajici data vyzaduji predevsim prave
> stabilitu dat.
ano, samozrejme, ale snapshot si viem zabezpecit aj sam - nacitam
data z databazy niekde do datasetu (myslim ten v .NET) a mam
snapshot. A nech ta uroven v databaze je hoci aj serializovana
ak to potrebujem.
> 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> striktni serializace transakci, tedy nulova paralelnost zpracovani.
> Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> stastne a spokojene bezet soucasne na plne obratky, staci jedna ktera
> zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do haje.
> Multigeneracni architektura velice ucinne izoluje transakce ktere
> pouze nebo predevsim ctou od zmen provedenych jinymi transakcemi,
> takze se navzajem neblokuji (pokud se ovsem spravne nastavi parametry
> transakci).
a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru treba
riesit? Na ukor inych operacii? Ja nevidim ziaden problem, ze ked idem
tlacit rozsiahlu zostavu, nacitam data do datasetu, odpojim sa
od databazy a mozem tlacit hoci aj tyzden tie data. A ten shaphot
mi ine neriesi, LEN to citanie dat. A aj to len vtedy ked nastane
taka konstelacia, ze treba citat vela zaznamov v transakcii, co
sa da IMHO velmi dobre eliminovat nacitanim si tych zaznamov
rovno do mojho programu. A pri zapisovani zaznamov v transakcii
zase len potrebujem serializaciu, cize ten shapshot ma nezachrani.
> 4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
> opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
> SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
> Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
> *specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
> starsi verze jsou v podstate ulozeny externe mimo databazi).
> Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
> sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
> obycejny bastl.
su to dost silne slova na databazy ako MS SQL a Oracle
ale mas samozrejme pravo na svoj nazor. Mozes uviest
aj nejake porovnania vykonu tejto architektury s inymi
architeturami napr. MS SQL?
Ja mam pocit, ze v MS SQL to implementovali ako jednu
z moznosti k niekokym uz existujucim moznostiam hlavne
koli ulahceniu prechodu na MS SQL z inych databaz, nie
z nejakej nevyhnutnosti.
Erik
Odpovedá: Petr Zahradnik
15. 10. 2004 23:45
Mimochodem, Pavle, ted jsem si precetl jeste ten zbytek, tak nekolik
reakci:
> 1. Ne vsechny transakce mohou byt kratke.
Kazdy rozumny (dle meho nazoru) vyvojar ti rekne (a v kazde seriozni
technicke literature o relacnich databazich se doctes), ze transakce
ma byt co mozna nejkratsi.
> Zatimco transakce modifikujici data jsou typicky kratke, transakce
> ktere data zpracovavaji
Takze data, ktera data zpracovavaji, data nemodifikuji? Ja myslel, ze
kazda transakce hlavne modifikuje data...
> (napr. ucetni uzaverka, preceni skladu, vyhodnoceni obratu na
> zakaznickem uctu apod.) jsou casto i velmi dlouhe.
IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti
byla ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil.
Notabene na co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba
pul hodiny nebo pul roku po te uzaverce. Takova ucetni uzaverka je ti
na dve veci v obou techto pripadech, takze nepomuze ani serializace.
IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
hodiny u pokladen, nez ti tato transakce dojede...
IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak kriticka
operace. Kdyz dojde k nejake nepresnosti, neni to zase az takova
tragedie. Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
nestane, kdyz tam nebude. Pokud to delas na konci mesice proto, abys
vyhodnotil nejake obdobi z duvodu treba nejake automaticke zmeny
rabatu, pak to opet delas nad uzavrenymi daty za minuly mesic. Je malo
pravdepodobne, ze nekdo neco stareho opravi zrovna ted, notabene
takova oprava stejne neni dost rozumna.
> 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> striktni serializace transakci, tedy nulova paralelnost zpracovani.
Jiste, to mas pravdu. Zrovna jako treba jedina bezpecna sifra je
Vernamova sifra, kde je klic stejne dlouhy jako data a opravdu
nahodny. Jenze to neni snadno dosazitelne, proto se pouzivaji jine
sifrovaci algoritmy, ktere nejsou 100% bezpecne, ale lze pristoupit na
danou miru bezpecnosti. Kdyz budes vyhodnocovat napriklad bezpecnost
site (ale i treba sveho bytu), take nikdy nebude 100% bezpecna, ale
musis pristoupit na urcitou miru rizika, ktera je pro tebe prijatelna.
Stejne je to s transakcemi. Kdyz pristoupis na serializaci, pak budes
mit misto SQL Serveru pomale orezavatko. Proto nedelaji database
design programy, ale lidi, kteri musi databazi navrhnout tak, aby
nebyla nutna serializace, pripadne aby se maximalne omezila, pricemz
se prihlizi k tomu, ze kolize nebo nepresnost muze nastat, ovsem
hlavne jde o to, jak moc velky problem to bude, a jak pravdepodobne to
bude. Navrhnout databazi s tim, ze se nastavi serializace, to umi
kazdy trubka. Ale navrhnout databazi tak, aby byla dostatecne vykonna
a presto co nejmene kolizni, to uz neni tak jednoduche.
A az ti do toho vstoupi i replikace, tak se kolizim stejne nevyhnes.
Ja tvrdim jednu vec - je lepsi s kolizemi pocitat, byt na ne pripraven
a umet je resit, nez se jim snazit za kazdou cenu vyhnout (tedy i za
tu cenu, ze udelas z SQL Serveru to serializovane orezavatko).
Mas to asi tak jako ze je lepsi pocitat s tim, ze ti pocitac shori,
takze budes delat pravidelne zalohy a budes mit pripraveny plan
obnovy. Je to mnohem lepsi nez mnohem vetsi energii (treba nekonecnou)
vynakladat na to, aby se to nikdy nemohlo stat. Jenze ono se to stejne
stane a pak ani vlastne nevis, co budes delat...
> Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> stastne a spokojene bezet soucasne na plne obratky, staci jedna
> ktera zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do
> haje.
Ne, ne, vsechno nejde do haje - v pripade, ze s tim pocitas a v
pripade, ze to je proste dane procento, kdy to lze tolerovat a skody
nejsou velike.
> Z pohledu architektury je to jak u Oracle tak u MS obycejny bastl.
Jo! Fuj! Nejlepsi je Firebird, ze?
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Pavel Cisar
16. 10. 2004 11:36
Haj hou!
On 15 Oct 2004 at 23:47, Winsoft wrote:
> > 1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
> > modifikujici data jsou typicky kratke, transakce ktere data
> > zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
> > obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
>
> a teraz zhodnotme ako tento problem riesi MGA: poskytne sice
> snapshot ale za cenu nasledneho zdlhaveho zbierania narobeneho
> smetia.
Ruzne implementace MGA (nebo tez MVCC - Multiversion concurrency
control) to resi ruzne. Firebird provadi odstranovani smeti prubezne,
takze za bezneho provozu je uroven smeti v databazi velmi nizka.
Problem muze vyvstat v extremnich pripadech, jako je vymaz x milionu
zaznamu ktery tuto debatu odstartoval, pripadne vymaz/zmena dat v
cele tabulce (zpusobuje "skytnuti"). Pokud si je vyvojar vedem
vlastnosti MGA, pak je schopen system navrhnout tak, aby i tyto
pripady nezpusobily vazne problemy.
> Takze ked robim uzavierku, najprv usetrim cas a neskor ho
> stratim. Aky je potom z toho celkovy efekt? Nehovoriac o tom,
> ze v dosledku takejto architektury ma system automaticky vecsiu
> reziu vlastne pri kazdej databazovej operacii.
To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
bezneho provozu ma rezii mensi, protoze zmenena data neni treba
odsouvat do externiho uloziste (transakcni protokol), ale v
optimalnim pripade se presouvaji pouze v ramci teze databazove
stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
vykonu kazdeho db systemu.
> Mne sa zda byt vyhodnejsie minimalizovat transakcne problemy komplexne,
> nie len zobrat jeden pripad (podla mna vobec nie typicky pripad)
> pouzitia a na nom vybudovat architekturu databazy.
MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
zjednodusuje cely system implementace atomicity operaci a izolace
transakci. MGA totiz nepouziva zamky, cimz se cela implementace
znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
"vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
systemu (zadne prehravani logu), automaticka podpora on-line
zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
nejsou problemy.
> > 2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
> > stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
> > transakce provadejici zmeny potrebuji spise atomicitu operaci,
> > protoze transakce zpracovavajici data vyzaduji predevsim prave
> > stabilitu dat.
>
> ano, samozrejme, ale snapshot si viem zabezpecit aj sam - nacitam
> data z databazy niekde do datasetu (myslim ten v .NET) a mam
> snapshot. A nech ta uroven v databaze je hoci aj serializovana
> ak to potrebujem.
A to myslis vazne ? Samotna operace vyberu a nacteni dat do datasetu
neprobehne v nulovem case. Pokud maji byt data korektni, pak musi by
operace provedena v izolacni urovni serializable (nebo alespon
repeatable read, ale ne vsechny db ji podporuji), coz u databazi
pouzivajicich zamky vylouci jakekoliv zmeny dat v ctenych tabulkach
po dobu behu transakce, tedy tvoje operace naplneni datasetu
zablokuje ostatni kteri chteji zmenu provest. Rovnez jakakoliv zmena
v datech ktere chces cist po odstartovani tve transakce zablokuje
tvou transakci. MGA nikoho nezablokuje, a je tedy jedno, zda si to
nactes do datasetu a pak to vytisknes z pameti, nebo to budes
prubezne sosat a tisknou z databaze. Bez MGA to typicky musis delat
pres dataset, aby jsi minimalizoval dobu behu sve transakce, a i
tehdy muzes mit problemy (pokud potrebujes vyloucit phantom rows), a
tedy dobu po kterou blokujes ostatni, s MGA je to jedno.
> a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru treba
> riesit? Na ukor inych operacii?
Na ukor jakych operaci ? Zmeny ? Vkladani ? Vymazu ? Jakych operaci ?
Chovani transakci u systemu s MGA i u systemu bez MGA je obecne
naprosto stejne, s tim rozdilem, ze implementace nevyuzivajici zamky
(MGA) umoznuje, aby operace cteni neblokovala zmenu dat (je-li to
pozadovano), a operace zmeny nezablokovala cteni (opet, je-li to
pozadovano). Bez MGA nemas na vyber, a musis hledat reseni problemu
mimo databazi (nacitani do datasetu apod.).
> > 4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
> > opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
> > SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
> > Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
> > *specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
> > starsi verze jsou v podstate ulozeny externe mimo databazi).
> > Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
> > sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
> > obycejny bastl.
>
> su to dost silne slova na databazy ako MS SQL a Oracle
> ale mas samozrejme pravo na svoj nazor. Mozes uviest
> aj nejake porovnania vykonu tejto architektury s inymi
> architeturami napr. MS SQL?
Neda se porovnovat vykon architektury, ale pouze vykon serveru. Na
vykon serveru ma vliv mnoho veci, nejen konkretni implementace
architektury transakci, takze vykon architektury se neda objektivne
zmerit, a tudiz ani srovnavat. Daji se srovnavat pouze vlastnosti.
Nicmene ja nezpochybnuji pouzitelnost a funkcnost MVCC implementace u
Oracle a MS. Muj nazor na implementaci MVCC u Oracle a SQLServeru
2005 se opira o fakt, ze MVCC je u nich nabastlena na zcela odlisnou
architekturu zamku a transakcniho logu. Je to jako ucit stareho psa
novym kouskum, na ktere neni fyziologicky staveny. Da se to, ale neni
to proste ono. Napr. u Oracle je MVCC implementovana na urovni celych
db stranek, tedy do transakcniho logu je pri kazde zmene db stranky
ulozena predchozi verze teto stranky. engine pak pro transakce v MVCC
rezimu (je to jen jedna spec. uroven izolace, nikoliv obecna
vlastnost systemu) dohleda prislusnou verzi stranky v logu. Jaky to
ma dopad na spotrebu diskoveho prostoru netreba zduraznovat, nemluve
o dopad na spravce vyrovnavaci pameti, pocet I/O operaci atd.. A to
se zde vubec nebavime o integraci MVCC do zbytku systemu z pohledu
vyvojare aplikaci, ktera vypada jako kdyz se michaji hrusky s mrkvi.
Pristup MS je mnohem rozumnejsi, protoze provadi verzovani na urovni
radku jako FB, ale opet je to navesene na odlisnou architekturu, se
vsemi neduhy ktere z toho plynou.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Pavel Cisar
16. 10. 2004 14:04
Haj hou!
On 16 Oct 2004 at 0:45, Petr Zahradnik wrote:
> Mimochodem, Pavle, ted jsem si precetl jeste ten zbytek, tak nekolik
> reakci:
>
> > 1. Ne vsechny transakce mohou byt kratke.
>
> Kazdy rozumny (dle meho nazoru) vyvojar ti rekne (a v kazde seriozni
> technicke literature o relacnich databazich se doctes), ze transakce
> ma byt co mozna nejkratsi.
Ano, to se rika a pise, a sam to tvrdim a pisu taky Problem je v
tom, ze ostatni vyvojari to casto ctou jinak nez jak je to napsano.
Pozadavek na co nejkratsi transakce znamena doslova toto:
Transakce by mela trvat nejkratsi moznou dobu nutnou na provedeni
pozadovane operace.
Pricemz "nejkratsi doba nezbytna pro provedeni operace" neni nijak
kvantifikovana, a klidne muze byt i par minut, hodin nebo dnu.
Bohuzel hodne lidi si to nejakym myslenkovym zkratem prelozi tak, ze
transakce trvajici dele nez par vterin jsou spatne, coz je naprosta
pitomost. Ze dlouhotrvajici transakce (prakticky jakehokoliv typu,
tedi i ciste R/O) u db enginu vyuzivajicich zamky a transakcni log
vetsinou vyrazne snizuji propustnost systemu a je tedy nutne nachazet
externi (z pohledu db) reseni a zkracovat je vice nez je z navrhu
systemu logicke, je problem implementace db enginu, nikoliv transakci
obecne.
MGA/MVCC tenhle problem znacne zjednodusuje, protoze eliminuje
nejcastejsi zdroj problemu spojeny s dlouhymi transakcemi.
> > Zatimco transakce modifikujici data jsou typicky kratke, transakce
> > ktere data zpracovavaji
>
> Takze data, ktera data zpracovavaji, data nemodifikuji? Ja myslel, ze
> kazda transakce hlavne modifikuje data...
1. Data jina data nezpracovavaji, data zpracovava kod v ramci
transakce.
2. Ne kazda transakce data musi cist, muze jen zapisovat (kdyz
ukladam zmeny provedene uzivatelem, nemusim vzdy hned neco cist), a
ne kazda transakce musi data zapisovat, muze je jen cist (napr. pro
tisk sestav neni typicky nutne nikam nic zapisovat). A pak jsou
transakce ktere ctou i zapisuji.
3. Pomer poctu jednotlivych typu transakci v ramci aplikace zalezi na
typu a zamereni aplikace a zpusobu specifikace transakci. Pokud tve
vlastni systemy vyzaduji, pripadne je navrhujes tak ze pouzivaji
pouze transakce ktere ctou i zapisuji, neznamena to, ze nic jineho
neexistuje, ale pouze ze v uzce vymezene oblasti ve ktere se
pohybujes jsi se s nicim jinym nesetkal.
> > (napr. ucetni uzaverka, preceni skladu, vyhodnoceni obratu na
> > zakaznickem uctu apod.) jsou casto i velmi dlouhe.
>
> IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
> hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
> konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti byla
> ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil. Notabene na
> co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba pul hodiny nebo
> pul roku po te uzaverce. Takova ucetni uzaverka je ti na dve veci v
> obou techto pripadech, takze nepomuze ani serializace.
1. Pokud by jsi zuzil problem pouze na data spadajici primo do
uzaverky, pak by jsi mel i pravdu, ale...
a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
rozsahu pripadneho konfliku (db stranky, indexy apod.).
b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
uzaverka) vztahovat nemusi.
2. Ucetni uzaverka byl jen priklad obecneho typu zpracovavane ulohy
ktery je ostatnim blizky. Jsou i jine ulohy obdobneho charakteru
ktere nemaji tak jednoznacne restrikce jako *ucetni* uzaverka. Navic
se konkretni situace muze v detailech lisit od predpokladaneho
standardu pro danou operaci.
> IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
> polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
> hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
> ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
> predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
> hodiny u pokladen, nez ti tato transakce dojede...
Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
stale neco precenuje.
> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak kriticka
> operace. Kdyz dojde k nejake nepresnosti, neni to zase az takova
> tragedie.
Takove veci jako ze nejaka ta nepresnost neni zadna tragedie vykladej
kterekoliv telekomunikacni spolecnosti, bance nebo pojistovne.
> Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
> drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
> kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
> ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
> nestane, kdyz tam nebude.
Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
> > 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> > striktni serializace transakci, tedy nulova paralelnost zpracovani.
>
> Jiste, to mas pravdu. Zrovna jako treba jedina bezpecna sifra je
> Vernamova sifra, kde je klic stejne dlouhy jako data a opravdu
> nahodny. Jenze to neni snadno dosazitelne, proto se pouzivaji jine
> sifrovaci algoritmy, ktere nejsou 100% bezpecne, ale lze pristoupit na
> danou miru bezpecnosti. Kdyz budes vyhodnocovat napriklad bezpecnost
> site (ale i treba sveho bytu), take nikdy nebude 100% bezpecna, ale
> musis pristoupit na urcitou miru rizika, ktera je pro tebe prijatelna.
>
> Stejne je to s transakcemi. Kdyz pristoupis na serializaci, pak budes
> mit misto SQL Serveru pomale orezavatko. Proto nedelaji database
> design programy, ale lidi, kteri musi databazi navrhnout tak, aby
> nebyla nutna serializace, pripadne aby se maximalne omezila, pricemz
> se prihlizi k tomu, ze kolize nebo nepresnost muze nastat, ovsem
> hlavne jde o to, jak moc velky problem to bude, a jak pravdepodobne to
> bude. Navrhnout databazi s tim, ze se nastavi serializace, to umi
> kazdy trubka. Ale navrhnout databazi tak, aby byla dostatecne vykonna
> a presto co nejmene kolizni, to uz neni tak jednoduche.
1. Struktura databaze s potrebou nebo nepotrebou serializace nema
vubec nic spolecneho. Michas hrusky s pomeranci. Struktura databaze
ma vliv na miru pravdepodobnosti a cetnosti kolizi. Pro zapis do
databaze je serializace nezbytna, a zadny db system s transakcemi (a
zadna uroven izolace transakci) ti jiny pristip nedovoli, i.e. dva
soubezne zapisy na totez misto zpusobi vzdy kolizi, a musi byt
serializovany. Rozdil je pouze ve zpusobu vyhodnoceni soft-kolize
mezi zapisem a ctenim. Z dovodu praktickych potreb je zaveden
kompromis mezi korektnosti dat a urovni paralelizace, pricemz
specifika tohoto kompromisu udava uroven izolace transakci.
Protoze system se zamky neumoznuje rozumne pouzitelnou izolaci cteni
a zapisu v podobe shapshotu pro cteni, a ze je tudiz nutne hledat
alternativni reseni problemu v aplikaci, casovani a strukture
transakci atd. jeste neznamena, ze pouziti techto nouzovych reseni je
normalni a ze to tak ma byt.
> Ja tvrdim jednu vec - je lepsi s kolizemi pocitat, byt na ne pripraven
> a umet je resit, nez se jim snazit za kazdou cenu vyhnout (tedy i za
> tu cenu, ze udelas z SQL Serveru to serializovane orezavatko).
Mas i nemas pravdu. Mas pravdu v pripade kolizi mezi zapisy, ale
nikoliv pri kolizi cteni a zapisu. Kolize zapisu je normalni vec, pri
dobrem navrhu databaze a transakci neni nijak casta, a neni problem
je poresit. Kolize cteni a zapisu je implementacni artefakt db enginu
*bez* MVCC/MGA, a s MGA nemusi byt ani zdaleka tak casty jak v realu
je bez MGA. Vyvojari kteri nepouzivaji MGA engine se toto omezeni
casem naucili nejak obchazet, nicmene ne vzdy se to da vyresit na
100% bez serializace. MGA tento resi prave problem jednoduse, ciste a
elegantne bez potreby serializace.
> > Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> > kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> > stastne a spokojene bezet soucasne na plne obratky, staci jedna
> > ktera zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do
> > haje.
>
> Ne, ne, vsechno nejde do haje - v pripade, ze s tim pocitas a v
> pripade, ze to je proste dane procento, kdy to lze tolerovat a skody
> nejsou velike.
>
> > Z pohledu architektury je to jak u Oracle tak u MS obycejny bastl.
>
> Jo! Fuj! Nejlepsi je Firebird, ze?
Nic takoveho jsem nenapsal. Nicmene Firebird (nejen) je na MGA
postaven, kdezto Oracle a MS SQLServer nikoliv, tudiz je do nich MVCC
"nejak" dobastlene. Jejich puvodni architektura na MVCC proste neni
stavena.
Je to podobne, jako kdyby VW utesnil Skodovku, pridal lodni sroub a
prohlasil to za skvely novy vuz ktery je i zavodni jachtou. Asi bude
plavat, nejspis se asi nepotopi, ale poradna lod to nebude. Navic to
urcite ovlivni i jeho jizdni schopnosti jako normalniho auta. O
problemech se zaskolovanim obsluhy nemluve.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Petr Zahradnik
16. 10. 2004 14:32
Pavle, nemam zrovna moc casu, tak jen telegraficky to nejdulezitejsi:
> MGA/MVCC tenhle problem znacne zjednodusuje, protoze eliminuje
> nejcastejsi zdroj problemu spojeny s dlouhymi transakcemi.
Ja hlavne vubec nereaguji na MGA/MVCC, jestli sis vsiml. Ja jen
reaguji na ty argumenty k dlouhotrvajicim transakcim...
>> IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
>> hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
>> konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti byla
>> ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil. Notabene na
>> co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba pul hodiny nebo
>> pul roku po te uzaverce. Takova ucetni uzaverka je ti na dve veci v
>> obou techto pripadech, takze nepomuze ani serializace.
> 1. Pokud by jsi zuzil problem pouze na data spadajici primo do
> uzaverky, pak by jsi mel i pravdu, ale...
> a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
> uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
> rozsahu pripadneho konfliku (db stranky, indexy apod.).
To mi prosim blize vysvetli. Ja v tom zadny zavazny nebo neresitelny
problem nevidim.
> b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
> ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
> uzaverka) vztahovat nemusi.
A z toho tedy vyvozujes co?
> 2. Ucetni uzaverka byl jen priklad obecneho typu zpracovavane ulohy
> ktery je ostatnim blizky. Jsou i jine ulohy obdobneho charakteru
> ktere nemaji tak jednoznacne restrikce jako *ucetni* uzaverka. Navic
> se konkretni situace muze v detailech lisit od predpokladaneho
> standardu pro danou operaci.
Ano, ja to chapu. Ale uvedl jsi tento priklad a ja na nej zareagoval.
Je to spatne?
>> IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
>> polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
>> hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
>> ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
>> predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
>> hodiny u pokladen, nez ti tato transakce dojede...
> Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
> prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
> v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
> stale neco precenuje.
A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
no a kdyz prijde k pokladne, muze se docela divit.
Takze precenovani zbozi v hypermarketu opet neni ten spravny pripad.
Vstupuje tam do hry vice faktoru, pricemz vlastni zmena ceny je oproti
ostatnim fyzickym kolizim na prodejne zcela zanedbatelna.
>> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak
>> kriticka operace. Kdyz dojde k nejake nepresnosti, neni to zase az
>> takova tragedie.
> Takove veci jako ze nejaka ta nepresnost neni zadna tragedie
> vykladej kterekoliv telekomunikacni spolecnosti, bance nebo
> pojistovne.
Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
udaje. Neni tam problem.
Banka - to je prilis neobecny pripad a tam se zrejme plne serializaci
v urcitych fazich nevyhnes, nicmene asi ne kazdy tu dela soft pro
banky. I kdyz bych ti taky mohl vypravet, co se leckdy na ucte
prihodi...
Pojistovna - tim myslis konkretne co? Kde je to kriticke misto?
>> Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
>> drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
>> kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
>> ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
>> nestane, kdyz tam nebude.
> Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
> ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
> rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
vysvetlovat, pro me za me... kazdy mame jine argumenty...
> 1. Struktura databaze s potrebou nebo nepotrebou serializace nema
> vubec nic spolecneho. Michas hrusky s pomeranci.
Navrh databaze ma s potrebou nebo nepotrebou serializace spolecneho
mnoho, rozhodne vic nez si myslis.
> Struktura databaze ma vliv na miru pravdepodobnosti a cetnosti
> kolizi.
Vsechno toto spolu uzce souvisi a nemuzes neco vynechat.
> Pro zapis do databaze je serializace nezbytna, a zadny db system s
> transakcemi (a zadna uroven izolace transakci) ti jiny pristip
> nedovoli, i.e. dva soubezne zapisy na totez misto zpusobi vzdy
> kolizi, a musi byt serializovany. Rozdil je pouze ve zpusobu
> vyhodnoceni soft-kolize mezi zapisem a ctenim. Z dovodu praktickych
> potreb je zaveden kompromis mezi korektnosti dat a urovni
> paralelizace, pricemz specifika tohoto kompromisu udava uroven
> izolace transakci.
No ja jen nechapu, co tim chces rici, jako v cem tedy argumentujes.
Pripominam, ze se bavime o dlouhotrvajicich transakcich, ktere
zpracovaji tuny dat po dlouho dobu.
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Winsoft
16. 10. 2004 15:30
> Ruzne implementace MGA (nebo tez MVCC - Multiversion concurrency
> control) to resi ruzne. Firebird provadi odstranovani smeti prubezne,
> takze za bezneho provozu je uroven smeti v databazi velmi nizka.
> Problem muze vyvstat v extremnich pripadech, jako je vymaz x milionu
> zaznamu ktery tuto debatu odstartoval, pripadne vymaz/zmena dat v
> cele tabulce (zpusobuje "skytnuti"). Pokud si je vyvojar vedem
> vlastnosti MGA, pak je schopen system navrhnout tak, aby i tyto
> pripady nezpusobily vazne problemy.
lenze paradoxne to je presne to spracovanie udajov, ktore by
ta MGA architektura mala riesit, koli ktoremu bola robena, nie?
Teda nie kratke transakcie ale dlhe. A neriesi to, ani nemoze riesit,
lebo riesi len polovicu problemu (citanie) a aj to za cenu
znacnych komplikacii - generovania smeti a jeho upratovania.
Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
transakciu v ktorej si budu prepisovat zaznamy, vysledkom
bude, ze nezbehne ani jedna ani druha transakcia. A mozu
tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
Cely efekt MGA je len v tom, ze namiesto riesenia problemu
sa zameni jeden problem za iny.
> To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
> bezneho provozu ma rezii mensi, protoze zmenena data neni treba
> odsouvat do externiho uloziste (transakcni protokol), ale v
> optimalnim pripade se presouvaji pouze v ramci teze databazove
> stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
> stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
> minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
> vykonu kazdeho db systemu.
Podla mna je neporovnatelne jednoduchsie a rychlejsie zamknut zaznam
a ukladat pripadne zmeny do trans. logu ako vyrabat a spravovat verzie
zaznamov a indexov.
> MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
> zjednodusuje cely system implementace atomicity operaci a izolace
> transakci. MGA totiz nepouziva zamky, cimz se cela implementace
> znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
> datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
> "vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
> systemu (zadne prehravani logu), automaticka podpora on-line
> zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
> pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
> clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
> nejsou problemy.
zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
nemoze byt takisto ziadny velky problem.
> A to myslis vazne ? Samotna operace vyberu a nacteni dat do datasetu
> neprobehne v nulovem case. Pokud maji byt data korektni, pak musi by
> operace provedena v izolacni urovni serializable (nebo alespon
> repeatable read, ale ne vsechny db ji podporuji), coz u databazi
> pouzivajicich zamky vylouci jakekoliv zmeny dat v ctenych tabulkach
> po dobu behu transakce, tedy tvoje operace naplneni datasetu
> zablokuje ostatni kteri chteji zmenu provest. Rovnez jakakoliv zmena
> v datech ktere chces cist po odstartovani tve transakce zablokuje
> tvou transakci. MGA nikoho nezablokuje, a je tedy jedno, zda si to
> nactes do datasetu a pak to vytisknes z pameti, nebo to budes
> prubezne sosat a tisknou z databaze. Bez MGA to typicky musis delat
> pres dataset, aby jsi minimalizoval dobu behu sve transakce, a i
> tehdy muzes mit problemy (pokud potrebujes vyloucit phantom rows), a
> tedy dobu po kterou blokujes ostatni, s MGA je to jedno.
takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
> Na ukor jakych operaci ? Zmeny ? Vkladani ? Vymazu ? Jakych operaci ?
> Chovani transakci u systemu s MGA i u systemu bez MGA je obecne
> naprosto stejne, s tim rozdilem, ze implementace nevyuzivajici zamky
> (MGA) umoznuje, aby operace cteni neblokovala zmenu dat (je-li to
> pozadovano), a operace zmeny nezablokovala cteni (opet, je-li to
> pozadovano). Bez MGA nemas na vyber, a musis hledat reseni problemu
> mimo databazi (nacitani do datasetu apod.).
existencia viacerych generacii zaznamov automaticky znamena
viac dat v databaze, teda pomalsi pristup, vyssie naroky na pamet,
atd. Kazda jedna databazova operacia to IMHO pociti.
> > su to dost silne slova na databazy ako MS SQL a Oracle
> > ale mas samozrejme pravo na svoj nazor. Mozes uviest
> > aj nejake porovnania vykonu tejto architektury s inymi
> > architeturami napr. MS SQL?
>
> Neda se porovnovat vykon architektury, ale pouze vykon serveru. Na
> vykon serveru ma vliv mnoho veci, nejen konkretni implementace
> architektury transakci, takze vykon architektury se neda objektivne
> zmerit, a tudiz ani srovnavat. Daji se srovnavat pouze vlastnosti.
nech uz porovnavam vlastnosti alebo konkretne implementacie, nevidim
ziadne extra vyhody pre MGA
> Nicmene ja nezpochybnuji pouzitelnost a funkcnost MVCC implementace u
> Oracle a MS. Muj nazor na implementaci MVCC u Oracle a SQLServeru
> 2005 se opira o fakt, ze MVCC je u nich nabastlena na zcela odlisnou
> architekturu zamku a transakcniho logu. Je to jako ucit stareho psa
> novym kouskum, na ktere neni fyziologicky staveny. Da se to, ale neni
> to proste ono. Napr. u Oracle je MVCC implementovana na urovni celych
> db stranek, tedy do transakcniho logu je pri kazde zmene db stranky
> ulozena predchozi verze teto stranky. engine pak pro transakce v MVCC
> rezimu (je to jen jedna spec. uroven izolace, nikoliv obecna
> vlastnost systemu) dohleda prislusnou verzi stranky v logu. Jaky to
> ma dopad na spotrebu diskoveho prostoru netreba zduraznovat, nemluve
> o dopad na spravce vyrovnavaci pameti, pocet I/O operaci atd.. A to
> se zde vubec nebavime o integraci MVCC do zbytku systemu z pohledu
> vyvojare aplikaci, ktera vypada jako kdyz se michaji hrusky s mrkvi.
myslim si, ze keby to bola naozaj taka skvela zalezitost, ako to su
popisujem
tak uz davno by ta multigeneracna architektura v MS SQL aj v Oracli bola.
Ale je to len jedna z moznosti, ktora riesi jeden ciastkovy (povedal by som
okrajovy) problem a preto tam zrejme nie je ziadny dovod budovat na tom
cely system.
Erik
Odpovedá: Pavel Cisar
16. 10. 2004 16:59
Haj hou1
On 16 Oct 2004 at 15:32, Petr Zahradnik wrote:
> > a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
> > uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
> > rozsahu pripadneho konfliku (db stranky, indexy apod.).
>
> To mi prosim blize vysvetli. Ja v tom zadny zavazny nebo neresitelny
> problem nevidim.
Je to problem obecne synchronizace typu MRSW (multiple reader, single
writer) na internich datovych strukturach db enginu, jako jsou napr.
indexy. Pro vyhodnoceni tveho dotazu je treba index ktery je menen z
jine transakce, pricemz ke kolizi dojde i kdyz ty primo vubec
nepotrebujes cist data (z tabulky) ktera jsou menena. Kolizni bod je
synchronizace pristupu k indexu jako takovemu. Problem to muze byt
dle okolnosti i dost zavazny, prostredky aplikace neresitelny.
Problem na ktery poukazuji je v tom, ze aplikacni programator ma
tendenci vnimat data v databazi na jine urovni jejich organizace nez
jak je vnima db engine. Skutecnost, ze ty prostor pro kolizi ze sveho
navrhu schematu nevidis, jeste neznamena, ze neexistuje.
> > b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
> > ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
> > uzaverka) vztahovat nemusi.
>
> A z toho tedy vyvozujes co?
Moznost kolize kterou ty apriori vylucujes argumentem, ze data
podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
Proto musi uzaverka pracovat prinejmensim v izolaci repeatable read
(aby nedochazelo k fluktuaci hodnot v ramci zpracovani), coz u
systemu se zamky okamzite vede ke kolizi cteni a zapisu. U MGA k tomu
dojit nemuze.
> > Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
> > prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
> > v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
> > stale neco precenuje.
>
> A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
> problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
> hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
> jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
> to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
> tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
> si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
> no a kdyz prijde k pokladne, muze se docela divit.
Je videt, ze o tom moc nevis. Praxe (v TESCO, ale zarucene i jinde)
je takova, ze pokud se cena snizuje, upravuje se nejdrive na kase (a
na samoobsluznych vahach co tisknou cenovky napr. pro zeleninu),
protoze zakaznik muze byt nesouladem s cenovkou na regalu pouze
prijemne prekvapen - zaplati mene nez cekal. Pak se tisknou a
aktualizuji cenovky na regale. Pokud se cena zvysuje, nejprve se
vytisknou cenovky, a teprve kdyz jsou na regalech, provede se
preceneni na kase.
> >> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak
> >> kriticka operace. Kdyz dojde k nejake nepresnosti, neni to zase az
> >> takova tragedie.
>
> > Takove veci jako ze nejaka ta nepresnost neni zadna tragedie
> > vykladej kterekoliv telekomunikacni spolecnosti, bance nebo
> > pojistovne.
>
> Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
> vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
> udaje. Neni tam problem.
Ted jsi me opravdu pobavil. Ty vydis jen jedinou moznost takoveho
zpracovani - tisk slozenky za obdobi zpetne. Jenze podobnych
zpracovani je mnoho druhu, vcetne vypoctu okamziteho zbyvajiciho
kreditu, pruzneho prepocitavani tarifu atd. Hodne podobnych
zpracovani se provadi *prubezne*. Pri on-line, realtimovem sberu dat
vyzaduje takove zpracovani vylouceni vyskytu phantom rows, coz se bez
snapshotu da zajistit *jen* izolacni urovni Serializable.
> > Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
> > ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
> > rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
>
> Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
> kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
> vysvetlovat, pro me za me... kazdy mame jine argumenty...
1. Tady nejde o odlisny nazor, ale o zvolene argumenty.
Argumentace typu letadla jsou zbytecna a nevim co na nich kdo vidi,
protoze ja nikam nelitam a kamkoliv potrebuji jsem se vzdy dostal
autem, lodi a vlakem vypovidaji jen o tvych zkusenostech, znalostech
a potrebach, ale neprinaseji nic k diskuzi o problematice obecneho
pouziti letadel, a jejich uzitecnosti.
2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
Co ti na to mam rict ? Snad jen ze IT neni jen o tom, co delas a znas
ty osobne. Za tvymi dvermi zacina cely svet, ktery je vetsi a
pestrejsi nez si mozna dovedes predstavit.
> > 1. Struktura databaze s potrebou nebo nepotrebou serializace nema
> > vubec nic spolecneho. Michas hrusky s pomeranci.
>
> Navrh databaze ma s potrebou nebo nepotrebou serializace spolecneho
> mnoho, rozhodne vic nez si myslis.
Serializace je metoda synchronizace pristupu ke sdilenym zdrojum.
Dokud bude databaze sdilena, bude pravdepodobnost kolize nenulova, a
jeji struktura na tom nic nezmeni. Potrebu serializace odstranis jen
zrusenim sdileni, nikoliv carovanim se strukturou sdileneho zdroje.
> > Struktura databaze ma vliv na miru pravdepodobnosti a cetnosti
> > kolizi.
>
> Vsechno toto spolu uzce souvisi a nemuzes neco vynechat.
Co vynechavam ?
> > Pro zapis do databaze je serializace nezbytna, a zadny db system s
> > transakcemi (a zadna uroven izolace transakci) ti jiny pristip
> > nedovoli, i.e. dva soubezne zapisy na totez misto zpusobi vzdy
> > kolizi, a musi byt serializovany. Rozdil je pouze ve zpusobu
> > vyhodnoceni soft-kolize mezi zapisem a ctenim. Z dovodu praktickych
> > potreb je zaveden kompromis mezi korektnosti dat a urovni
> > paralelizace, pricemz specifika tohoto kompromisu udava uroven
> > izolace transakci.
>
> No ja jen nechapu, co tim chces rici, jako v cem tedy argumentujes.
> Pripominam, ze se bavime o dlouhotrvajicich transakcich, ktere
> zpracovaji tuny dat po dlouho dobu.
Nejde o dlouhe transakce jako takove, jde o transakce ktere data
ctou, a ktere zaroven vyzaduji uroven stability ctenych dat vyssi nez
Read Committed. Shodou okolnosti jde velmi casto prave o transakce
ktere zpracovavaji velke mnozstvi dat, a tudiz trvaji dlouho. To
problem prohlubuje, ale nikoliv zapricinuje. Problem je v
implementaci synchronizace pristupu ke sdilenym datum pomoci zamku,
ktera vede ke kolizim mezi operacemi cteni a zapisu, ke kterym pri
jinem stylu implementace (MGA/MVCC) vubec nedochazi. System s MGA ma
bez potreby zmeny ve strukture transakci a databaze mnohem mensi
procento kolizi nez jine systemy, protoze muze dojit pouze ke kolizim
soubeznych zapisu, ktere nejsou tak caste ani tak rozsahle.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Petr Zahradnik
16. 10. 2004 18:23
Stale nemam moc casu, tak zase jen telegraficky:
> Moznost kolize kterou ty apriori vylucujes argumentem, ze data
> podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
> podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
> spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
> strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
Kdyz ti to nekdo zmeni pred nebo po uzaverce, tak mas vysledek stejny
jako v prubehu uzaverky - v obou pripadech je to problem.
>> A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
>> problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
>> hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
>> jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
>> to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
>> tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
>> si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
>> no a kdyz prijde k pokladne, muze se docela divit.
> Je videt, ze o tom moc nevis. Praxe (v TESCO, ale zarucene i jinde)
> je takova, ze pokud se cena snizuje, upravuje se nejdrive na kase (a
> na samoobsluznych vahach co tisknou cenovky napr. pro zeleninu),
> protoze zakaznik muze byt nesouladem s cenovkou na regalu pouze
> prijemne prekvapen - zaplati mene nez cekal. Pak se tisknou a
> aktualizuji cenovky na regale. Pokud se cena zvysuje, nejprve se
> vytisknou cenovky, a teprve kdyz jsou na regalech, provede se
> preceneni na kase.
Jasne, ze ja jako demagog o tom nic nevim. Muzes mi jako odbornik na
hypermarket vysvetlit, kde tedy nastane ten problem, kdyz v prubehu
transakce zmeny ceny zrovna nekdo neco chce zaplatit na pokladne, a
tedy dostane bud starsi nebo novejsi cenu? Bude jako prijemne
prekvapen nebo nemile prekvapen? Je snad nejaky rozdil mezi tim, kdyz
tam bude hodinu pendlovat a mezitim nekdo zmeni cedulku?
A zaver je tedy jako jaky? Ze mi vysvetlis, jak v Tescu pobihaji
zamestnanci (nebo jezdi na koleckovych bruslich) s cedulkama? Kde je
ten problem v databazi? To mi rekni - kde je problem v transakci
preceneni, kdyz nebude plne serializovana?
>> Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
>> vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
>> udaje. Neni tam problem.
> Ted jsi me opravdu pobavil. Ty vydis jen jedinou moznost takoveho
Auau, to to boli, kdyz to vidim ^^^^^^^
> zpracovani - tisk slozenky za obdobi zpetne. Jenze podobnych
> zpracovani je mnoho druhu, vcetne vypoctu okamziteho zbyvajiciho
> kreditu, pruzneho prepocitavani tarifu atd.
No a kdyz znas Tesco, znas taky Go a Twist, jak tam funguji ty
kredity? Jsi si vazne jisty, ze treba SMSky nemuzes precerpat? Zkousel
jsi to?
>> Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
>> kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
>> vysvetlovat, pro me za me... kazdy mame jine argumenty...
> 1. Tady nejde o odlisny nazor, ale o zvolene argumenty.
No vsak jo, ja se ti snazim oponovat a ty mi na to odpovidas, ze je to
demagogie. Ani by me neprekvapilo, kdybys nevedel, co to slovo
znamena, kdyz ho pouzivas v tomto kontextu.
> Argumentace typu letadla jsou zbytecna a nevim co na nich kdo vidi,
> protoze ja nikam nelitam a kamkoliv potrebuji jsem se vzdy dostal
> autem, lodi a vlakem vypovidaji jen o tvych zkusenostech, znalostech
> a potrebach, ale neprinaseji nic k diskuzi o problematice obecneho
> pouziti letadel, a jejich uzitecnosti.
Jaky zase letadlo?
> 2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
Pavle, prosim prejdi z pluralu na singular - jestli chces zacit flame,
ja na to opravdu nemam cas. Pokud neumis diskutovat na urovni
slusnosti, tak se vazne s tebou nemam o cem bavit. Napadat ostatni
(nejen me, ale treba Erika), to by umel kdekdo. Tahle konference neni
o tom, kdo koho umi rychleji a kvetnateji poslat do prdele, ani o tom,
kdo koho umi nazyvat demagogy nebo co od koho tu casto slysime. Jestli
chces, abych na tvoje nazory nereagoval, tak to jednoduse uplne nahoru
do prispevku napis, a muzes tu mit klidne sve monology a ja si to budu
cist a nebudu komentovat a ty si je zase muzes treba lepit na
nastenku.
> Co ti na to mam rict ? Snad jen ze IT neni jen o tom, co delas a
> znas ty osobne. Za tvymi dvermi zacina cely svet, ktery je vetsi a
> pestrejsi nez si mozna dovedes predstavit.
Ano, s tim ja souhlasim. A proto striktne odmitam tva "jedina
pravdiva" reseni
vsech problemu na celem svete. Ja se ti tu snazim
vysvetlit, ze vsechno zalezi na konkretnim pripadu a na konkretnim
database designu a na konkretnich podminkach a na vyhodnoceni moznych
kolizi a jejich pravdepodobnosti a jejich moznych nasledku a na mire
rizika a reseni takovych stavu.
Kdyz si ja nebo kdokoliv jiny neco nedovede predstavit, tak tady
financuji tuhle konferenci prave proto, ze je tu snad dost chytrych
lidi, kteri to vysvetlit dokazi, kteri se v tom pohybuji. A opravdu,
Pavle, nejsem zvedavy na to, abys mi tu nadaval do demagogu a ostatnim
rovnou rikal, ze ze sebe delaji blazny.
Ja se moc rad necham poucit. Ale jestli me chces poucovat o tom, ze ja
jsem demagog, ze argumentuji urcitym priblblym stylem, a ze ostatni ze
sebe delaji blazny, tak se obavam, ze tim nikoho zrovna moc nepoucis.
A me rozhodne ne.
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Pavel Cisar
16. 10. 2004 18:37
Haj hou!
On 16 Oct 2004 at 16:30, Winsoft wrote:
> lenze paradoxne to je presne to spracovanie udajov, ktore by
> ta MGA architektura mala riesit, koli ktoremu bola robena, nie?
> Teda nie kratke transakcie ale dlhe. A neriesi to, ani nemoze riesit,
> lebo riesi len polovicu problemu (citanie) a aj to za cenu
> znacnych komplikacii - generovania smeti a jeho upratovania.
1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
pristupy maji sve vyhody i nevyhody.
2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
architektur.
3. Jak je videt, MGA neni principialne odlisna od architektury zamku
a transakcniho logu. Oba pristupy resi stejny problem a potykaji se
se stejnymi prekazkami, pouze technicke reseni maji odlisne. Oba
pristupy maji sve prednosti i nevyhody.
> Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
tedy argument ?
> > To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
> > bezneho provozu ma rezii mensi, protoze zmenena data neni treba
> > odsouvat do externiho uloziste (transakcni protokol), ale v
> > optimalnim pripade se presouvaji pouze v ramci teze databazove
> > stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
> > stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
> > minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
> > vykonu kazdeho db systemu.
>
> Podla mna je neporovnatelne jednoduchsie a rychlejsie zamknut zaznam
> a ukladat pripadne zmeny do trans. logu ako vyrabat a spravovat verzie
> zaznamov a indexov.
To je jen tvuj osobni nazor. Kolik databazi jsi uz implementoval,
pripadne jejich implementaci prostudoval ? Vis vubec kolik *typu*
zamku potrebuje takovy lock&log db engin ktery neni urcen jen na
hrani ? Co musi delat aby to vsechno ukociroval ?
Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
pokud takova transakce precte par set tisic radku, o milionech
nemluve ?
(napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
zamku, pak jsi na omylu).
Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
1. Ziskani zamku na db stranku (jen po dobu I/O)
2. Presun stavajiciho radku v ramci stranky, pokud je to ucelne, tak
pouze jako delta k nove hodnote radku, a tudiz mensi. Pokud nelze
puvodni verzi ulozit na stenou stranku, pak se presune na jinou
stranku kde je misto (ta se pracne nehleda, system o takovych
strankach "vi").
3. Ulozeni nove hodnoty radku na misto puvodniho.
I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
...horsi nes nasledujici obecny postup u Lock&Log:
1. Ziskani zamku na radek (do konce transakce), pripadne zmena typu
zamku (napr. pokud uz byl radek cten, tak zmena z share lock na write
lock apod.) a db stranku (jen po dobu I/O)
2. Nacteni stavajici hodnoty radku, transformace dat do struktury pro
transakcni log a zapis do logu.
3. Zapis nove hodnoty radku na misto puvodniho.
I/O: vzdy zapis aktualni db stranky + zapis do logu.
At to vezmu z kterekoliv strany, mezi obojim pristupem v *principu*
neni zadny rozdil. Puvodni hodnotu radku je vzdy treba vzit a nekam
odsunout, a novou zapsat na jeho puvodni pozici. Rozdil je pouze v
nezbytnych transformacich datovych struktur, poctu I/O a absenci
zamku na radky u MGA. Nicmene MGA toho provadi mene, s mensim
mnozstvim datovych struktur a podstatne jednodussim kodem. Mohli by
jsme to sice objektivne zmerit, ale uz z takto hrubeho popisu lze
dovodit, ze by rychlejsi a jednoduss mela byt spise MGA, nikoliv
naopak.
> > MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
> > zjednodusuje cely system implementace atomicity operaci a izolace
> > transakci. MGA totiz nepouziva zamky, cimz se cela implementace
> > znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
> > datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
> > "vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
> > systemu (zadne prehravani logu), automaticka podpora on-line
> > zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
> > pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
> > clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
> > nejsou problemy.
>
> zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
> nemoze byt takisto ziadny velky problem.
Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
zmeny jejich charakteru za provozu systemu.
> takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
pravdepodobnosti kolize nic spolecneho.
2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
vykon nijak zasadni vliv.
Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
stale jeste obcas ma, protoze Borland sprasil garbage collection
thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
takove, pouze o konkretni implementaci.
> existencia viacerych generacii zaznamov automaticky znamena
> viac dat v databaze, teda pomalsi pristup, vyssie naroky na pamet,
> atd. Kazda jedna databazova operacia to IMHO pociti.
Zvysovani velikosti databaze automaticky neznamena *vyrazne*
pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
vyssi naroky na pamet.
> nech uz porovnavam vlastnosti alebo konkretne implementacie, nevidim
> ziadne extra vyhody pre MGA
Ze zadne vyhody nevidis ovsem nedokazuje ze zadne neexistuji,
dokazuje to pouze ze ty osobne zadne nevidis.
> myslim si, ze keby to bola naozaj taka skvela zalezitost, ako to su
> popisujem tak uz davno by ta multigeneracna architektura v MS SQL aj v
> Oracli bola. Ale je to len jedna z moznosti, ktora riesi jeden
> ciastkovy (povedal by som okrajovy) problem a preto tam zrejme nie je
> ziadny dovod budovat na tom cely system.
Pokud by MVCC/MGA bylo naprosto zbytecne, pak by se Oracle nikdy
neobtezoval ji do sve databaze doplnit (a to uz pomerne davno). Pokud
vim ja, tak MVCC je oblibenym argumentem pri kazdem tendru kde stoji
Oracle proti DB2 od IBM. A tvrdit, ze MS doplnuje MVCC do SQLServeru
*jen* kvuli pretahovani zakazniku od Oracle je rovnez ponekud
kratkozrake.
Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
pouziva prave MGA/MVCC ?
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Ludek ZITA
16. 10. 2004 19:34
On Behalf Of Petr Zahradnik
[Pavel Cisar]
> > Moznost kolize kterou ty apriori vylucujes argumentem, ze data
> > podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
> > podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
> > spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
> > strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
>
[Petr Zahradnik]
> Kdyz ti to nekdo zmeni pred nebo po uzaverce, tak mas
> vysledek stejny jako v prubehu uzaverky - v obou pripadech je
> to problem.
Ahoj,
No ja bych si dovolil souhlasit s Pavlem Cisarem. Protoze nejde jen o
data, ale take o indexy nad hlavnimi i ciselnikovymi tabulkami.
To na vysledek uzaverky (z pohledu platnych dat) vliv nema, ale kolize
mezi zapisem a ctenim na indexu jiste vznikne.
Ludek
Odpovedá: Winsoft
17. 10. 2004 17:04
> 1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
> jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
> uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
> pristupy maji sve vyhody i nevyhody.
namiesto generovania smetia sa pocka na odomknutie zaznamu
> 2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
> Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
> pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
> ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
> smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
> je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
> architektur.
povedal by som, ze cistit databazu od neplatnych zaznamov
je narocnejsia zalezitost ako cistit trans. log. S trans. logom
je ovela menej problemov to je neporovnatelne.
> > Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> > transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> > bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> > tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
>
> Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
> zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
> tedy argument ?
v pripade zamkov je daleko vyssia sanca na ukoncenie aspon
jednej z tychto transakcii. A hovoris vykonstruovany priklad?
IMHO je to jednoduchy priklad na dlhe transakcie s moznymi
koliziami, nic ine. Teda to, co ma MDA riesit. Najprv ma kritizujes
ked hovorim, ze treba kratke transakcie a neskor ked uvediem
priklad na dlhe, tak hovoris, ze je to v praxi nezmysel. Tak
sa skus najprv sam ujednotit na tych transakciach.
> To je jen tvuj osobni nazor. Kolik databazi jsi uz implementoval,
> pripadne jejich implementaci prostudoval ? Vis vubec kolik *typu*
> zamku potrebuje takovy lock&log db engin ktery neni urcen jen na
> hrani ? Co musi delat aby to vsechno ukociroval ?
jednu suborovu databazu som implementoval. Ale to nie je
dolezite. Ze sa pouzivaju rozne zamky to je vsetko otazka
optimalizacie (napr. preco zamykat kazdy zaznam extra, ked
potrebujem zamknut celu tabulku). Zamok je jednoduchy
mechanizmus ale ked treba zamykat vela zaznamov je logicke,
ze sa to optimalizuje.
> Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
> radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
> nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
> pokud takova transakce precte par set tisic radku, o milionech
> nemluve ?
>
> (napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
> zamku, pak jsi na omylu).
ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
ked sa zmaze vela zaznamov?
> Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
>
> I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
>
> ...horsi nes nasledujici obecny postup u Lock&Log:
>
> I/O: vzdy zapis aktualni db stranky + zapis do logu.
a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
extra pre kazdu generaciu zaznamu?
> At to vezmu z kterekoliv strany, mezi obojim pristupem v *principu*
> neni zadny rozdil. Puvodni hodnotu radku je vzdy treba vzit a nekam
> odsunout, a novou zapsat na jeho puvodni pozici. Rozdil je pouze v
> nezbytnych transformacich datovych struktur, poctu I/O a absenci
> zamku na radky u MGA. Nicmene MGA toho provadi mene, s mensim
> mnozstvim datovych struktur a podstatne jednodussim kodem. Mohli by
> jsme to sice objektivne zmerit, ale uz z takto hrubeho popisu lze
> dovodit, ze by rychlejsi a jednoduss mela byt spise MGA, nikoliv
> naopak.
ja by som to predsa len radsej objektivne zmeral 
> > zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
> > nemoze byt takisto ziadny velky problem.
>
> Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
> zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
> zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
> zmeny jejich charakteru za provozu systemu.
mozno tie rozne typy zamkov su tam prave preto aby sa dal
redukovat pocet zamkov a ta sprava bola rychlejsia
> > takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> > vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> > taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> > riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> > kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
>
> 1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
> pravdepodobnosti kolize nic spolecneho.
dlhsia transakcia znamena vecsiu sancu, ze pocas jej vykonavania
sa vyskytne ina transakcia, nie? A viac transakcii zas vecsiu sancu
na koliziu medzi nimi, nie?
> 2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
> funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
> spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
> vykon nijak zasadni vliv.
tak preco tam treba vobec robit to zbieranie smetia? Ved ked to smetie
nema na vykon vplyv, tak je IMHO zbytocne to pravidelne spustat.
> Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
> stale jeste obcas ma, protoze Borland sprasil garbage collection
> thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
> byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
> takove, pouze o konkretni implementaci.
tak preco to neopravis (alebo niektory z uzivatelov), ved je to open source,
architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
je problem?
> Zvysovani velikosti databaze automaticky neznamena *vyrazne*
> pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
> vyssi naroky na pamet.
RAMka zvykne byt rychlejsia ako disk a preto je asi vyhodne
vyuzit ju ako cache. No a cim viac RAMky na cache, tym viac
dat sa do nej vmesti a praca s nimi potom rychlejsia. No a co sa tyka
velkosti diskovej pamete, tak smetie vytvarane v MDA na velkosti
databazy asi neuberie, skor napak
> Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
> MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
> technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
> nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
> spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
> zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
> pouziva prave MGA/MVCC ?
aha, takze Microsoft a Oracle si nemozu ekonomicky dovolit
implementovat MGA. Na rozdiel od akejsi firmicky (neviem
si teraz spomenut ako sa vlastne vola), ktora robi MySQL.
Zvlastna logika.
Erik
Odpovedá: Pavel Cisar
17. 10. 2004 20:18
On 17 Oct 2004 at 18:04, Winsoft wrote:
> > 1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
> > jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
> > uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
> > pristupy maji sve vyhody i nevyhody.
>
> namiesto generovania smetia sa pocka na odomknutie zaznamu
??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
vzdy uchovat, bez ohledu na architekturu kterou zvolis.
> > 2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
> > Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
> > pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
> > ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
> > smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
> > je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
> > architektur.
>
> povedal by som, ze cistit databazu od neplatnych zaznamov
> je narocnejsia zalezitost ako cistit trans. log. S trans. logom
> je ovela menej problemov to je neporovnatelne.
To mas samozrejme pravdu, ale odsunem puvodnich hodnot do logu
zaroven znacke komlikujes jejich dostupnost, a tedy rozumnou
implementaci snapshotu. A bez snapshotu nektere operace proste nejdou
rozumne udelat. V obou pripadech jde o kompromis, protoze zatim nikdo
neprisel na postup, ktery by dovoloval mit obe vlastnosti za stejne
"nizkou" cenu. Navic odstranovani smeti neni az takovy problem.
> > > Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> > > transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> > > bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> > > tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
> >
> > Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
> > zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
> > tedy argument ?
>
> v pripade zamkov je daleko vyssia sanca na ukoncenie aspon
> jednej z tychto transakcii.
Proc myslis ze je to u MGA jinak ? MGA nema zamky na radky, protoze
je nepotrebuje, anzto stejnou funkci jakou maji zamky realizuji
samotne verze. Kolize zapisu je tedy detekovana u obou architektur
naprosto stejne.
> A hovoris vykonstruovany priklad?
Ano, protoze zadne transakce si nemohou jak ty pises
"vzajemne
prepisovat zaznamy". Ta ktera prijde jako druha bude mit proste
smulu, skonci s chybou (a na architekture nezalezi). Mozna te i
prekvapi, ze MGA ma oproti systemu se zamky prakticky nulovou moznost
vzniku deadlocku.
> Ze sa pouzivaju rozne zamky to je vsetko otazka optimalizacie (napr.
> preco zamykat kazdy zaznam extra, ked potrebujem zamknut celu tabulku).
> Zamok je jednoduchy mechanizmus ale ked treba zamykat vela zaznamov je
> logicke, ze sa to optimalizuje.
Prave ze je nutne to optimalizovat upgradem typu zamku, napr. z row
lock na page lock, pripadne i table lock. Tim se prakticky eliminuje
vyhoda radkovych zamku pro transakce ktere meni vetsi mnozstvi dat,
pripadne vetsi mnozstvi ctou v izolaci Repeatable Read. Co to v praxi
znamena je ti urcite jasne, obzvlaste pokud jsi pracoval s nejakou
databazi ktera nemela zamky na jednotlive radky (napr. MS SQLServer
pred verzi 7). Proste des bes.
> > Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
> > radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
> > nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
> > pokud takova transakce precte par set tisic radku, o milionech
> > nemluve ?
> >
> > (napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
> > zamku, pak jsi na omylu).
>
> ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> ked sa zmaze vela zaznamov?
Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
nutne.
> > Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
> >
> > I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
> >
> > ...horsi nes nasledujici obecny postup u Lock&Log:
> >
> > I/O: vzdy zapis aktualni db stranky + zapis do logu.
>
> a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> extra pre kazdu generaciu zaznamu?
Ne, indexy verzovane nejsou, pouze radky.
> > Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
> > zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
> > zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
> > zmeny jejich charakteru za provozu systemu.
>
> mozno tie rozne typy zamkov su tam prave preto aby sa dal
> redukovat pocet zamkov a ta sprava bola rychlejsia
Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
vyhaneni certa dablem (viz nasledky lock promotion)
> > > takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> > > vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> > > taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> > > riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> > > kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
> >
> > 1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
> > pravdepodobnosti kolize nic spolecneho.
>
> dlhsia transakcia znamena vecsiu sancu, ze pocas jej vykonavania
> sa vyskytne ina transakcia, nie? A viac transakcii zas vecsiu sancu
> na koliziu medzi nimi, nie?
Ano, ale to prece plati obecne pro jakykoliv system, nejde o nejake
specifikum MGA. MGA v takovych scenarich moznost kolize zapisu nijak
nezvysi, naopak eliminaci moznosti kolize mezi ctenim a zapisem
umoznuje provoz dele trvajicim transakcim i v situacich, ve kterych
by to u systemu se zamky nebylo mozne.
> > 2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
> > funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
> > spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
> > vykon nijak zasadni vliv.
>
> tak preco tam treba vobec robit to zbieranie smetia? Ved ked to smetie
> nema na vykon vplyv, tak je IMHO zbytocne to pravidelne spustat.
Smeti zacina mit vliv na vykon pouze kdyz je ho opravdu hodne. Do 15%
objemu databze to temer nelze merit. Vyjimkou jsou extremne dlouhe
retezce verzi, ale ty vznikaji pouze kdyz se aplikace zamerne navrhne
urcitym konkretnim zpusobem (coz nikdo se znalosti MGA nikdy
neudela).
> > Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
> > stale jeste obcas ma, protoze Borland sprasil garbage collection
> > thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
> > byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
> > takove, pouze o konkretni implementaci.
>
> tak preco to neopravis (alebo niektory z uzivatelov), ved je to open source,
> architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
> je problem?
A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
precist co jsem puvodne napsal.
> > Zvysovani velikosti databaze automaticky neznamena *vyrazne*
> > pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
> > vyssi naroky na pamet.
>
> RAMka zvykne byt rychlejsia ako disk a preto je asi vyhodne
> vyuzit ju ako cache. No a cim viac RAMky na cache, tym viac
> dat sa do nej vmesti a praca s nimi potom rychlejsia. No a co sa tyka
> velkosti diskovej pamete, tak smetie vytvarane v MDA na velkosti
> databazy asi neuberie, skor napak
Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
databaze bobtna i bez smeti.
> > Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
> > MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
> > technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
> > nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
> > spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
> > zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
> > pouziva prave MGA/MVCC ?
>
> aha, takze Microsoft a Oracle si nemozu ekonomicky dovolit
> implementovat MGA. Na rozdiel od akejsi firmicky (neviem
> si teraz spomenut ako sa vlastne vola), ktora robi MySQL.
> Zvlastna logika.
Takze jeste jednou a po lopate: Architektura ovlivnuje implementaci
mnoha dalsich subsystemu db enginu. Prepracovat napr. Oracle plne na
MGA by znamenalo prepsat ho skoro cely. Navic by nebylo jednoduche
dodrzet zpetnou kompatibilitu vsech vlastnosti a vychytavek ktere
obsahuje (dost jich je napsanych "na telo" systemu zamku a logu,
pripadne ma implementacne zavisly interface). U systemu rozsahu
Oracle to tedy neni ekonomicky unosne. U MySQL se transakce teprve
implementovaly, takze si mohli svobodne vybrat, jak je udelaji.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Winsoft
17. 10. 2004 22:52
> > namiesto generovania smetia sa pocka na odomknutie zaznamu
>
> ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> vzdy uchovat, bez ohledu na architekturu kterou zvolis.
V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
a komitnut aj druha transakcia. Samozrejme kommit sa neda
ani tu zarucit a neda sa vylucit ani deadlock, ale sanca na zbehnutie
tych transakcii je tu celkom ina. Dokonca aj v pripade deadlocku
sa v MS SQL rollback robi len u jednej transkacii, tam kde
je jednoduchsi (cize mozme predpokladat ze u tej, ktora bola
neskor spustena - a teda po jej opetovnom spusteni uz moze zbehnut).
A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
vtedy ked to bolo potrebne.
Zamky mi teda umoznuju rychlejsie detekovat a predist konfliktom
v transakciach za cenu cakania, ked je zamknute. To sa mi vidi
dobre riesenie, pricom system zamkov je velmi jednoduchy
na pochopenie aj implementovanie (kto si spusti napr. MS SQL
si to moze aj lahko overit). A su moznosti urcovat izolaciu
transakcii, alebo aj automaticky optimalizovat zamky alebo povedzme
zamknut aj celu databazu ak potrebujem co najrychlejsie a s istotou
zbehnut nejaku surnu transakciu. A tento system je velmi vyhodny
pre kratke transakcie, teda typicke transakcie u beznych aplikacii
Skratka osvedcena a overena architektura. Musela by byt ovela
vyhodnejsia ina architektura aby sa vyplatilo prejst na inu. A takou
IMHO teda MDA architektura nie je.
> > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > ked sa zmaze vela zaznamov?
>
> Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> nutne.
praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
konfliktom pesimisticky ale optimisticky
> > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > extra pre kazdu generaciu zaznamu?
>
> Ne, indexy verzovane nejsou, pouze radky.
ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych generaciach
zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje ).
> > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > redukovat pocet zamkov a ta sprava bola rychlejsia
>
> Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> vyhaneni certa dablem (viz nasledky lock promotion)
IMHO to je elegantne riesenie problemu. Optimalizuje
sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
cache sa niekedy nacitaju nepotrebne udaje aj predpoved
vetvevenia skoku v procesore sa obcas netrafi. No a co?
Dolezite je, ze vecsinou to funguje a celkovo sa teda
vykonnost zvysi.
> > tak preco to neopravis (alebo niektory z uzivatelov), ved je to open
source,
> > architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
> > je problem?
>
> A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
> precist co jsem puvodne napsal.
tak mozme uz teda porovnat vykon IB a MS SQL?
> Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
> velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
> databaze bobtna i bez smeti.
ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Erik
Odpovedá: Martin Schayna
17. 10. 2004 23:42
Winsoft wrote:
> tak mozme uz teda porovnat vykon IB a MS SQL?
Ja bych byl pro.
Shodou okolnosti mame ted postavenou malou farmicku
se servery Sun a IBM a deviti stejnymi klienty, meli jsme ji
na Invexu (pav. V stanek c.4 ABRA). Navrhete oba,
Pavel i Erik, nejaky test proti stejne naplnene databazi
se stejnymi tabulkami, ktery by otestoval obe
architektury...
Otestovat muzeme treba FB CS 1.5 a Oracle 9.2
na Linuxu (jestli se nepletu tak MS SQL na Linuxu
nebezi).
Martin Schayna
www.aktis.cz
Odpovedá: Milan Tomes
18. 10. 2004 6:09
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Sunday, October 17, 2004 11:53 PM
>
> > > namiesto generovania smetia sa pocka na odomknutie zaznamu
> >
> > ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> > vzdy uchovat, bez ohledu na architekturu kterou zvolis.
>
> V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
> generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
> ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
> a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
> medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
> z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
>
> V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
transakci tak je preci situace naprosto stejna - je ohlasena chyba a
transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s MGA
architekturou nepracoval.
> A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> a komitnut aj druha transakcia. Samozrejme kommit sa neda
> ani tu zarucit a neda sa vylucit ani deadlock, ale sanca na zbehnutie
> tych transakcii je tu celkom ina. Dokonca aj v pripade deadlocku
> sa v MS SQL rollback robi len u jednej transkacii, tam kde
> je jednoduchsi (cize mozme predpokladat ze u tej, ktora bola
> neskor spustena - a teda po jej opetovnom spusteni uz moze zbehnut).
Tak ci onak reseni tohoto stavu zavisi na programatorovi a ne na serveru -
princip je uplne stejny bez ohledu na architekturu. Jak MGA tak i lock
system ohlasi chybu v konkretni transakci. Jestli jsi jeste nepochopil
princip MGA, tak vez, ze Pavel se Ti snazil dost dlouho vysvetlit, ze nejde
o chybu pri zapisovani (rozumej UPDATE) jednoho zaznamu ve dvou transakcich
(tam to totiz vzdycky bez ohledu na architekturu skonci stejne), ale o
pouzivani read (rozumej SELECT) a write (rozumej UPDATE, INSERT) soucasne a
tam mi prijde architektura MGA vyhodnejsi. Zkratka a jednoduse klidne mohu
cist jeden konkretni zaznam i v pripade, ze mi jina transakce tento zaznam
zmenila a nemam s tim zadny problem - ctu totiz verzi platnou pri startovani
transakce (samozrejme zalezi na nastavene urovni izolace).
> A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> vtedy ked to bolo potrebne.
Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
smeti, ktere je naprosto nepotrebne ???
>
> Zamky mi teda umoznuju rychlejsie detekovat a predist konfliktom
> v transakciach za cenu cakania, ked je zamknute. To sa mi vidi
> dobre riesenie, pricom system zamkov je velmi jednoduchy
> na pochopenie aj implementovanie (kto si spusti napr. MS SQL
> si to moze aj lahko overit). A su moznosti urcovat izolaciu
> transakcii, alebo aj automaticky optimalizovat zamky alebo povedzme
> zamknut aj celu databazu ak potrebujem co najrychlejsie a s istotou
> zbehnut nejaku surnu transakciu. A tento system je velmi vyhodny
> pre kratke transakcie, teda typicke transakcie u beznych aplikacii
> Skratka osvedcena a overena architektura. Musela by byt ovela
> vyhodnejsia ina architektura aby sa vyplatilo prejst na inu. A takou
> IMHO teda MDA architektura nie je.
Evidentne jsi nikdy v zivote architekturu MGA nepouzil. Ale treba jsi takovy
genius, ze dokazes naprosto dokonale predvidat vsechny stavy Tveho programu,
takze nejaky deadlock Ti proste nehrozi 
Ja se vyvojem na FireBirdem nejaky ten rok zabyvam a i pri velice dlouhych
transakcich (podivej se na komponenty IBX) se mi jeste NIKDY nestalo, ze
bych se dostal do deadlocku a pritom naprosto standardne pouzivam situaci
kdy jedna transakce (R/O) cte a druha updatuje data prectena tou prvni
transakci. Tohle by naprosto spolehlive polozilo MSSQL na zada (soude dle
drive napsaneho P. Cisarem, Tebou a dokumentace k MSSQL) - ale take je
mozne, ze pravdu nemam
>
> > > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > > ked sa zmaze vela zaznamov?
> >
> > Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> > ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> > nutne.
>
> praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> konfliktom pesimisticky ale optimisticky
Skoro se mi chce napsat, ze optimisticke reseni je i v zivote vyhodnejsi nez
pesimisticke, ale zalezi to na uhlu pohledu...
>
> > > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > > extra pre kazdu generaciu zaznamu?
> >
> > Ne, indexy verzovane nejsou, pouze radky.
>
> ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> generaciach
> zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
> nejako neviem najst uspokojive riesenie (co neznamena, ze
> neexistuje ).
Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud byl nejaky
zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
verzim radku.
>
> > > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > > redukovat pocet zamkov a ta sprava bola rychlejsia
> >
> > Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> > vyhaneni certa dablem (viz nasledky lock promotion)
>
> IMHO to je elegantne riesenie problemu. Optimalizuje
> sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
> cache sa niekedy nacitaju nepotrebne udaje aj predpoved
> vetvevenia skoku v procesore sa obcas netrafi. No a co?
> Dolezite je, ze vecsinou to funguje a celkovo sa teda
> vykonnost zvysi.
>
> > > tak preco to neopravis (alebo niektory z uzivatelov), ved je to open
> source,
> > > architektura je jednoducha, prinos by bol znacny (alebo
> nie?), tak v com
> > > je problem?
> >
> > A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
> > precist co jsem puvodne napsal.
>
> tak mozme uz teda porovnat vykon IB a MS SQL?
Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
proste rychlejsi ??? Gratuluju... 
>
> > Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
> > velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
> > databaze bobtna i bez smeti.
>
> ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni, tak
by soucasne pevne disky meli mit cache nekolik GB a procesory take... Prosim
podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to samozrejme
plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen zapisovat
nova data, tak preci nepotrebuji 1GB cache ne ???
S pozdravem
Milan Tomes
Odpovedá: Milan Tomes
18. 10. 2004 6:15
Ahoj,
co presne myslis tim "zacvicit" s constraints ???
Zrusit a znovu vytvorit ???
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Pavel Cisar
> Sent: Friday, October 15, 2004 11:15 AM
>
> odstraneni smeti z indexu. Proto je nanejvyse vhodne po hromadnem
> vymazu nebo zmene cca 1/3 radku v tabulce ihned deaktivovat a
> opetovne aktivovat indexy (u FK je nutne "zacvicit" s constraints, PK
> se da vetsinou preskocit). Pri takovych operacich by s db nemel nikdo
> dalsi pracovat, anzto je to bepecnejsi a predevsim mnohem rychlejsi.
Odpovedá: Pavel Cisar
18. 10. 2004 8:38
Haj hou!
On 18 Oct 2004 at 7:15, Milan Tomes wrote:
> co presne myslis tim "zacvicit" s constraints ???
>
> Zrusit a znovu vytvorit ???
Ano, presne tak.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Marek Spisak
18. 10. 2004 9:47
>>>Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
>>>velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
>>>databaze bobtna i bez smeti.
>>>
>>>
>>ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
>>nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
>>Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
>>podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
>>
>>
>
>Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni, tak
>by soucasne pevne disky meli mit cache nekolik GB a procesory take... Prosim
>podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
>nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to samozrejme
>plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
>nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen zapisovat
>nova data, tak preci nepotrebuji 1GB cache ne ???
>
souhlas, mame FB databaze o celkem slusne velikosti - nejvetsi ma pres
10 GB, DB server ma 1 GB pameti a jede to slusne. Proc by se musela
databaze nacpat cela do pameti aby slusne jela??? Zalezi na navrhu
databaze, indexaci... Vetsinu databazi bych do pameti nenarval ani
kdybych se rozkrajel ;). Nehlede na to, ze na jednom FB serveru nam bezi
mnohdy vice nez 1 databaze.
Marek.
Odpovedá: Karel Rys
18. 10. 2004 10:18
Winsoft dne 15 Oct 2004 v 23:47:
> a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru
> treba riesit? Na ukor inych operacii? Ja nevidim ziaden problem, ze
> ked idem tlacit rozsiahlu zostavu, nacitam data do datasetu, odpojim
> sa od databazy a mozem tlacit hoci aj tyzden tie data. A ten shaphot
> mi ine neriesi, LEN to citanie dat. A aj to len vtedy ked nastane taka
> konstelacia, ze treba citat vela zaznamov v transakcii, co sa da IMHO
> velmi dobre eliminovat nacitanim si tych zaznamov rovno do mojho
> programu. A pri zapisovani zaznamov v transakcii zase len potrebujem
> serializaciu, cize ten shapshot ma nezachrani.
A co treba takova zaloha velke databaze za provozu? U MGA zadny problem,
zatimco znamy se se
zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze netvrdim,
ze to nejak udelat
nejde).
Do datasetu sice lze, nepohodlne, leccos nacist, ale kdyz to za me udela
spolehlive server...
Potiz s datasety bude prinejmensim v tom, ze po siti tahas spoustu dat (tabulka
muze mit miliony
zaznamu) a po celou tu dobu ti je nesmi nikdo odjinud zmenit, jinak uz to neni
snapshot, ale gulas
V MGA je nekdo zmenit muze, ale ty porad vidis data pred zmenou. Tedy pokud
to tak chces a
transakci na snapshot nastavis, samozrejme. Jinak pokud sestava neni zrovna
primitivni a taha si
data z ruznych tabulek a je typu master-detail, tak si ty datasety taky uzij
Karel Rys
Odpovedá: Miso
18. 10. 2004 10:43
----- Original Message -----
From: "Petr Zahradnik" <clexpert@clexpert.cz>
> > 2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
>
> Pavle, prosim prejdi z pluralu na singular - jestli chces zacit flame,
..kludne sa Pavol moze vyjadrovat v plurale, ja zdielam ten isty nazor..
Michal
Odpovedá: Pavel Cisar
18. 10. 2004 11:42
Haj hou!
On 17 Oct 2004 at 23:52, Winsoft wrote:
> > > namiesto generovania smetia sa pocka na odomknutie zaznamu
> >
> > ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> > vzdy uchovat, bez ohledu na architekturu kterou zvolis.
>
> V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
> generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
> ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
> a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
> medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
> z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
zvolenou architekturu, to same co jsi napsal plati i pro system se
zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
zbytecne.
Je tu ovsem jeden podstatny rozdil. Zatimco system se zamky musi pri
rollbacku pracne rekonstruovat puvodni stav databaze, u systemu s MGA
se jednoduse zaznamena novy stav transakce - rollback, a je hotovo. V
pripade Firebirdu jde o zmenu dvou bitu v bitove mape stavu
transakci.
> V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
prvni pripad.
2. Chovani systemu s MGA a bez MGA je naprosto stejne. Pokud
transakce narazi na zmenu z jine transakce, muze cekat, nebo muze
ihned nahlasit chybu. Toto chovani proste neni zadne specifikum
systemu se zamky. Jeste jednou: system s MGA nema specialni datovou
strukturu a obsluzny mechanizmus pro zamek na radek, protoze
naprosto stejne funkcionality dosahne i bez teto struktury a
obsluzneho kodu. Existence novejsi verze radku funguje naprosto
stejne, jako kdyby byl na radek uvalen zamek.
> A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> a komitnut aj druha transakcia.
Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
odvolana.
> > > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > > ked sa zmaze vela zaznamov?
> >
> > Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> > ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> > nutne.
>
> praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> konfliktom pesimisticky ale optimisticky
1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
2. Kazdy system se zamky se snazi co nejblize priblizit
optimistickemu zamykani, proto pouziva mnoho ruznych typu zamku.
3. I system s MGA umoznuje pesimisticke zamykani, pokud si ho vyvojar
aplikace explicitne vyzada.
> > > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > > extra pre kazdu generaciu zaznamu?
> >
> > Ne, indexy verzovane nejsou, pouze radky.
>
> ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych generaciach
> zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
> nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje ).
Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
kontext.
Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
druhou stranu odpadaji jakekoliv hratky s indexem v pripade
rollbacku, problemy synchronizace transakci na indexech apod. ktere
postihuji systemy bez MGA.
> > > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > > redukovat pocet zamkov a ta sprava bola rychlejsia
> >
> > Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> > vyhaneni certa dablem (viz nasledky lock promotion)
>
> IMHO to je elegantne riesenie problemu. Optimalizuje
> sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
> cache sa niekedy nacitaju nepotrebne udaje aj predpoved
> vetvevenia skoku v procesore sa obcas netrafi. No a co?
> Dolezite je, ze vecsinou to funguje a celkovo sa teda
> vykonnost zvysi.
Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
"falesnych" kolizi.
> ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
umeru mezi velikosti cache a ucinnosti cache, protoze:
1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
careful write dle orientovanych grafu zavislosti v ramci cache u
kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
mechanizmus rizeni obsahu atd.)
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Winsoft
18. 10. 2004 11:51
> A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
> vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
ale preco mi podsuvas veci, ktore som nepovedal? Dokonca som jasne
povedal (hned v nasledujucom odstavci) ze ani kommit ani deadlock
sa neda vylucit ani v pripade zamkov, ale je tam vecsia pravdepodobnost,
ze k tomu nedojde, pretoze zamky tomu mozu zabranit. Myslim si,
ze som to velmi jasne napisal ako je to so zamkami a kto chcel tak ten
rozdiel IMHO pochopil. No smejes sa potom naozaj neviem na com.
> > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
>
> V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
> transakci tak je preci situace naprosto stejna - je ohlasena chyba a
> transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s
MGA
> architekturou nepracoval.
to ma byt snad opet zase provokacia? Zamok existuje aj na citanie, nielen
pri kolizii zapisu. Evidentne si so zamkovou architekturou nepracoval.
> > A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> > vtedy ked to bolo potrebne.
>
> Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
> smeti, ktere je naprosto nepotrebne ???
nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia,
ze zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia
zastavi az ked vznikne konflikt.
> Evidentne jsi nikdy v zivote architekturu MGA nepouzil. Ale treba jsi
takovy
> genius, ze dokazes naprosto dokonale predvidat vsechny stavy Tveho
programu,
> takze nejaky deadlock Ti proste nehrozi
naozaj vtipne, hlavne ked som to netvrdil. Skus hovorit viac za seba
a menej za mna. A ked uz hovoris za mna, tak pouzi citaciu z mojho
textu a nie vlastne zmyslaniny. Predideme tak zbytocnym konfliktom.
> > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> > generaciach
> > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
vysvetli,
> > nejako neviem najst uspokojive riesenie (co neznamena, ze
> > neexistuje ).
>
> Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud byl nejaky
> zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
> transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
> verzim radku.
stale tomu nerozumiem , preto uvediem priklad:
Mam zaznam s menom na ktorom je index. Nech prvy zaznam
obsahuje meno Erik a pouziva ho prva transakcia. Nech druha
transakcia chce zmenit jeho obsah, tak vyrobi novu generaciu
tohto zaznamu s menom Patrik. A teraz sa pytam ako je to s
indexom? Prva transakcia potrebuje index na zaznam Erik
druha zas index na zaznam Patrik, tak ako dostane prva
transkacia ten index na Erik a druha na Patrik? Je to jasne
ale mam este nejako dovysvetlovat tento jednoduchy priklad?
> > tak mozme uz teda porovnat vykon IB a MS SQL?
>
> Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
> proste rychlejsi ??? Gratuluju...
moje pointa spociva len v tom, nazorne vyskusat, ci sa a ako
tie vselijake teoreticke vyhody prejavia prakticky. Lebo ja neviem
na svojom pocitaci pouzit architekturu ako taku, nakreslenu
niekde na papieri ale len jej konkretnu implementaciu.
> > ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> > nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> > Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> > podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
>
> Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni,
tak
> by soucasne pevne disky meli mit cache nekolik GB a procesory take...
Prosim
> podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
> nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to
samozrejme
> plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
> nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen
zapisovat
> nova data, tak preci nepotrebuji 1GB cache ne ???
tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
procesorovu cache, ked spomaluje. A zmensi si RAMku,
ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
nezapisoval ten 1GB bez cache a s cache, tak si to
radsej najprv vyskusaj.
Erik
Odpovedá: Milan Tomes
18. 10. 2004 12:03
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 12:20 PM
>
> > A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
> > vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
>
> ale preco mi podsuvas veci, ktore som nepovedal? Dokonca som jasne
> povedal (hned v nasledujucom odstavci) ze ani kommit ani deadlock
> sa neda vylucit ani v pripade zamkov, ale je tam vecsia pravdepodobnost,
> ze k tomu nedojde, pretoze zamky tomu mozu zabranit. Myslim si,
> ze som to velmi jasne napisal ako je to so zamkami a kto chcel tak ten
> rozdiel IMHO pochopil. No smejes sa potom naozaj neviem na com.
Smeji se tomu jak to vyznelo a to byl opravdu blud. Omlouvam se, ze jsem
okamzite nepochopil velikost Tveho mysleni, ale uz jsem takovy a Ty me
urcite nezmenis...
>
> > > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
> >
> > V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
> > transakci tak je preci situace naprosto stejna - je ohlasena chyba a
> > transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s
> MGA
> > architekturou nepracoval.
>
> to ma byt snad opet zase provokacia? Zamok existuje aj na citanie, nielen
> pri kolizii zapisu. Evidentne si so zamkovou architekturou nepracoval.
Vysvetli mi, prosim, co je na tomto textu za provokaci.
>
> > > A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> > > vtedy ked to bolo potrebne.
> >
> > Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
> > smeti, ktere je naprosto nepotrebne ???
>
> nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia,
> ze zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
> pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia
> zastavi az ked vznikne konflikt.
Ach jo... Jak to, ze nedelas smeti v transakcnim logu, kdyz sen teprve
uprostred transakce narazi na zamknuty zaznam ??? To je preci nesmysl. Krom
jineho nechapu, proc bych nemohl cist zaznam, ktery *pouze* cetla jina
transakce.
> > > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> > > generaciach
> > > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
> vysvetli,
> > > nejako neviem najst uspokojive riesenie (co neznamena, ze
> > > neexistuje ).
> >
> > Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud
> byl nejaky
> > zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
> > transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
> > verzim radku.
>
> stale tomu nerozumiem , preto uvediem priklad:
>
> Mam zaznam s menom na ktorom je index. Nech prvy zaznam
> obsahuje meno Erik a pouziva ho prva transakcia. Nech druha
> transakcia chce zmenit jeho obsah, tak vyrobi novu generaciu
> tohto zaznamu s menom Patrik. A teraz sa pytam ako je to s
> indexom? Prva transakcia potrebuje index na zaznam Erik
> druha zas index na zaznam Patrik, tak ako dostane prva
> transkacia ten index na Erik a druha na Patrik? Je to jasne
> ale mam este nejako dovysvetlovat tento jednoduchy priklad?
No a ja Ti na to odpovim uplne stejne - transakce vidi takova data, ktera
byla videt pri jejim zahajeni. Je opravdu tak veliky problem pochopit tak
primitivni odpoved ???
>
> > > tak mozme uz teda porovnat vykon IB a MS SQL?
> >
> > Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
> > proste rychlejsi ??? Gratuluju...
>
> moje pointa spociva len v tom, nazorne vyskusat, ci sa a ako
> tie vselijake teoreticke vyhody prejavia prakticky. Lebo ja neviem
> na svojom pocitaci pouzit architekturu ako taku, nakreslenu
> niekde na papieri ale len jej konkretnu implementaciu.
Zkus se podivat na ten smajlik na konci vety...
>
> > > ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> > > nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> > > Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> > > podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
> >
> > Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni,
> tak
> > by soucasne pevne disky meli mit cache nekolik GB a procesory take...
> Prosim
> > podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to
> preci vubec
> > nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to
> samozrejme
> > plati analogicky pro soubor - muze me cache dokonce zpomalovat.
> Vzdycky je
> > nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen
> zapisovat
> > nova data, tak preci nepotrebuji 1GB cache ne ???
>
> tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
> procesorovu cache, ked spomaluje. A zmensi si RAMku,
> ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
> nezapisoval ten 1GB bez cache a s cache, tak si to
> radsej najprv vyskusaj.
Vis co - zacni s temi citacemi u sebe. Ja jsem reagoval jen a jen na blabol
typu: "Cim vetsi databaze, tim vic cache je potreba". To je naprosty
nesmysl. Je samozrejme, ze cache na disku i procesoru je velkym zrychlenim,
ale v nekterych pripadech je samozrejme i zpomalenim. Zkus se nad tim trosku
vice do hloubky zamyslet a urcite prijdes na to proc.
S pozdravem
Milan Tomes
Odpovedá: Pavel Cisar
18. 10. 2004 12:35
Haj hou!
On 18 Oct 2004 at 12:19, Winsoft wrote:
> nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia, ze
> zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
> pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia zastavi
> az ked vznikne konflikt.
1. Nova verze vznika jen pri zapisu, nikoliv pri cteni. Pokud jiz
existuje nova nepotvrzena verze, pak se samozrejme zadna dalsi verze
nevytvari, protoze je jasne ze nemuzu prepsat nepotvrzenou zmenu svou
vlastni. Je to stejne, jako by byl na radku zamek. V danem okamziku
muze existovat pouze jedina nepotvrzena verze radku.
2. Pokud radek ctu, pak samozrejme nebranim jinym ho zmenit. U
systemu se zamky k tomu pri cteni dochazi jen u izolace Repeatable
Read a vyssi. System se zamky ma v takovem pripade vyhodu, ze je
garantovano, ze nacteny radek bude mozne rovnez zmenit. To MGA
implicitne negarantuje, pokud neni vyzadan explicitni pesimisticky
zamek. Na druhou stranu system se zamky nedava na vyber, a prectena
data jsou "chranena" proti zapisu, at uz o to stojim nebo ne. U MGA
si muzu presne vybrat, a dostanu co chci.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Richard Kejval
18. 10. 2004 12:47
Ahoj do konference,
Winsoft wrote:
> tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
> procesorovu cache, ked spomaluje. A zmensi si RAMku,
> ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
> nezapisoval ten 1GB bez cache a s cache, tak si to
> radsej najprv vyskusaj.
Myslim, ze uz to pomalu ztraci "sportovni uroven".. Kdo
nema klapky na ocich, tak uz si nazor o MGA udelal a
ja musim jen Erikovi podekovat, ze vyprovokoval Pavla
k celkem podrobnemu popisu problemu. Takze jestli slo
jen o to, tak 3x bravo Eriku !!!
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware.cz
Odpovedá: Winsoft
18. 10. 2004 14:04
> A co treba takova zaloha velke databaze za provozu? U MGA zadny problem,
zatimco znamy se se
> zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze
netvrdim, ze to nejak udelat
> nejde).
neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal s tym
nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to bolo
kriticke?
Viem akurat tolko, ze v MS SQL je (aj) moznost inkrementalnych backupov.
U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia, ktora
bude zapisovat, tak sa budu generovat nove zaznamy, co znamena naslednu
zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
transakcii,
tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
transkacii
lebo v dosledku zatazenia systemu zalohovanim je predpoklad, ze transakcie
budu trvat dlhsie.
Erik
Odpovedá: Milan Tomes
18. 10. 2004 14:11
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 3:04 PM
>
> > A co treba takova zaloha velke databaze za provozu? U MGA zadny problem,
> zatimco znamy se se
> > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze
> netvrdim, ze to nejak udelat
> > nejde).
>
> U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia, ktora
> bude zapisovat, tak sa budu generovat nove zaznamy, co znamena naslednu
> zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
> transakcii,
> tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
> transkacii
> lebo v dosledku zatazenia systemu zalohovanim je predpoklad, ze transakcie
> budu trvat dlhsie.
Proboha co je zase tohle za pip ???
Pochopis uz konecne, ze se nic nekomplikuje ???
Proste se nastartuje nativne podporovana transakce typu snapshot a uz se
zalohuje.
Vysvetli mi co je na tomhle tak sloziteho a jakou roli v tom hraje delka
nejake transakce. V dobe zalohovani klidne muzou bezet dalsi transakce a
nicemu to nevadi. Zalohovani totiz do databaze vubec nic nezapisuje ale jen
cte existujici data. Pochop prosim, ze kdyz znas MS SQL a/nebo Oracle, tak
to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line zalohovani
na MS SQL.
S pozdravem
Milan Tomes
Odpovedá: Lstiburek Pavel
18. 10. 2004 15:09
Pri zalohovani MSSQL se zalohuji data pouze dokoncenych transakci,
nedokoncene transakce (dle logu) nejsou do zalohy preneseny. Stejne se
chova k transakcim zahajenym po okamziku zahajeni zalohy, at uz byly
nebo nebyly dokonceny.
DB lze obnovit k danemu okamziku (start BACKUP) s tim, ze vsechny
"rozjete" transakce jsou ztraceny. Podrobneji viz popis v BOL.
Pavel
> From: Milan Tomes [mailto:delphi@haida.cz]
> > [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> >
> > > A co treba takova zaloha velke databaze za provozu? U MGA
> zadny problem,
> > zatimco znamy se se
> > > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro
> neznam, takze
> > netvrdim, ze to nejak udelat
> > > nejde).
> >
> > U MGA ziadny problem? Ak pocas zalohovania pobezi ina
> transakcia, ktora
> > bude zapisovat, tak sa budu generovat nove zaznamy, co
> znamena naslednu
> > zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
> > transakcii,
> > tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
> > transkacii
> > lebo v dosledku zatazenia systemu zalohovanim je
> predpoklad, ze transakcie
> > budu trvat dlhsie.
>
> Proboha co je zase tohle za pip ???
> Pochopis uz konecne, ze se nic nekomplikuje ???
> Proste se nastartuje nativne podporovana transakce typu
> snapshot a uz se
> zalohuje.
>
> Vysvetli mi co je na tomhle tak sloziteho a jakou roli v tom
> hraje delka
> nejake transakce. V dobe zalohovani klidne muzou bezet dalsi
> transakce a
> nicemu to nevadi. Zalohovani totiz do databaze vubec nic
> nezapisuje ale jen
> cte existujici data. Pochop prosim, ze kdyz znas MS SQL
> a/nebo Oracle, tak
> to neznamena, ze znas vse. Opravdu si nedokazu predstavit
> on-line zalohovani
> na MS SQL.
>
Odpovedá: Richard Kejval
18. 10. 2004 14:35
Winsoft wrote:
> neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal s
tym
> nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to bolo
> kriticke?
> Viem akurat tolko, ze v MS SQL je (aj) moznost inkrementalnych backupov.
U MGA prirustkove zalohovani z principu neni mozne, proto u velkych databazi
backup trva podstatne dele nez u databazi s lock&log architekturou a to je
jedna
z nevyhod MGA, ale myslim, ze ty vyhody, ktere tu zminil Pavel by to mely
vyvazit
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware.cz
Odpovedá: Karel Rys
18. 10. 2004 15:02
Winsoft dne 18 Oct 2004 v 15:03:
> > A co treba takova zaloha velke databaze za provozu? U MGA zadny
> > problem,
> zatimco znamy se se
> > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam,
> > takze
> netvrdim, ze to nejak udelat
> > nejde).
>
> neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal
> s tym nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to
> bolo kriticke? Viem akurat tolko, ze v MS SQL je (aj) moznost
> inkrementalnych backupov.
Podnikovy informacni system. Zalohovani bezi automaticky na serveru - a bezi
tak casto, jak
zakaznik chce - tj. krome zalohovani o pulnoci (kteremu nevadi, kdyz nekdo
omylem aplikaci necha
pustenou) muze bezet treba kazde dve hodiny i pres den, zatimco uzivatele
vesele pracuji.
> U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia,
> ktora bude zapisovat, tak sa budu generovat nove zaznamy, co znamena
> naslednu zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac
> takych transakcii, tak sa to este viac skomplikuje. Zvysuje sa totiz
> riziko konfliktov transkacii lebo v dosledku zatazenia systemu
> zalohovanim je predpoklad, ze transakcie budu trvat dlhsie.
Zalohovani bezi podobne jako jiny SQL dotaz, takze jestli ma server momentalne
obslouzit 20
uzivatelu, nebo 20 uzivatelu plus zalohovani, uz nebude velky rozdil.
Je samozrejme pravda, ze kdyz nekdo v tu chvili zapisuje, vznikne nova verze
zaznamu, protoze tu
starou musi server kvuli snapshotu uchovat. Vzhledem k celkovemu objemu
databaze je to ale v
podstate zanedbatelne a nejblizsi garbage collection nebo sweep to odstrani.
Velmi podstatne ale
je, ze se udela zaloha, aniz by nekdo musel pobihat po firme a vyhanet lidi z
aplikace.
Karel Rys
Odpovedá: Pavel Cisar
18. 10. 2004 14:56
Haj hou!
On 18 Oct 2004 at 15:35, Richard Kejval wrote:
> U MGA prirustkove zalohovani z principu neni mozne, proto u velkych
> databazi backup trva podstatne dele nez u databazi s lock&log
> architekturou a to je jedna z nevyhod MGA, ale myslim, ze ty vyhody,
> ktere tu zminil Pavel by to mely vyvazit
Implementovat prirustkove zalohovani nad MGA mozne samozrejme je, jen
ho nelze realizovat tak jednoduse jako on-line zalohovani, a na
logicke urovni kde pracuje gbak. Soucasti Firebirdu 2.0 by mel byt
novy nastroj nbackup, ktery provadi i viceurovnove prirustkove
zalohovani na fyzicke urovni databazovych stranek, podrobnosti na
http://firebird.sourceforge.net/index.php?op=devel&sub=engine&id=nback
up
pozor na zalomeni URL)
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Milan Tomes
18. 10. 2004 15:42
Diky za informaci - neni nad to si rozsirit obzory...
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Lstiburek Pavel
> Sent: Monday, October 18, 2004 3:32 PM
>
> Pri zalohovani MSSQL se zalohuji data pouze dokoncenych transakci,
> nedokoncene transakce (dle logu) nejsou do zalohy preneseny. Stejne se
> chova k transakcim zahajenym po okamziku zahajeni zalohy, at uz byly
> nebo nebyly dokonceny.
> DB lze obnovit k danemu okamziku (start BACKUP) s tim, ze vsechny
> "rozjete" transakce jsou ztraceny. Podrobneji viz popis v BOL.
Odpovedá: Winsoft
18. 10. 2004 15:50
> Podnikovy informacni system. Zalohovani bezi automaticky na serveru - a
bezi tak casto, jak
> zakaznik chce - tj. krome zalohovani o pulnoci (kteremu nevadi, kdyz nekdo
omylem aplikaci necha
> pustenou) muze bezet treba kazde dve hodiny i pres den, zatimco uzivatele
vesele pracuji.
a ako sa riesi zmena programu alebo databazy, ked dojde k zmene legislativy,
alebo zmene struktury alebo fungovania podniku, alebo chyby v programe?
To vsetko sa riesi za chodu systemu za plnej prevadzky? Aky je to podnik,
ze sa tam pracuje aj v nedelu a cez sviatky s informacnym systemom?
Erik
Odpovedá: Slavomir Skopalik
18. 10. 2004 16:08
> systemu za plnej prevadzky? Aky je to podnik, ze sa tam
> pracuje aj v nedelu a cez sviatky s informacnym systemom?
Napriklad:
CZ Strakonice, a.s.
Kingspan, a.s.
TRZ - Valcovna Bohumin
Vsude je FB a full backup kazdych 8 hodin.
Provoz jede nepretrzite (az na vyjimky).
Pro zasadni zmeny se dohodne odstavka (v radu hodin).
Slavek
Odpovedá: Winsoft
18. 10. 2004 21:56
> Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
> teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
> zvolenou architekturu, to same co jsi napsal plati i pro system se
> zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
> zbytecne.
tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
z hladiska mozneho generovania zbytocneho smetia prejavi:
Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
ako T2):
1. Optimisticke zamykanie (MGA)
Transakcia1 Transakcia2
precita 'Erik' precita 'Erik'
nieco robi zapise 'Patrik' (ako novu generaciu)
nieco robi nieco robi
nemoze zapisat 'Fero' nieco robi
rollback commit
Teda Transakcia2 zbehla ale Transkacia1 nie. To znamena,
ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
(v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
tie zaznamy su nanic a teda vzniklo smetie. Cize Transakcia1
bezala a zatazovala system zbytocne a okrem mozneho smetia,
zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
nic nevyriesila.
2. Pesimisticke zamykanie so zamkami
Transakcia1 Transakcia2
precita 'Erik' nemoze precitat (zamknute), tak caka
nieco robi caka
nieco robi caka
zapise 'Fero' caka
nieco robi caka
commit odomknute, precita 'Fero'
zapise 'Patrik'
nieco robi
nieco robi
commit
Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni zamok.
Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj komitnute.
Aj v systeme so zamkami ale mozu vzniknut deadlocky a transakcia
vtedy nezbehne (napr. ked sa zamknuty zaznam zisti neskoro a dovtedy
samotna transakcia zamkla ine zaznamy).
> > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
>
> 1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
> zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
> prvni pripad.
MS SQL caka na odomknutie, pricom je mozne definovat timeout.
Prednastavene je nekonecne cakanie. Samozrejme deadlocky
sa detekuju, po ich zisteni sa uz necaka ale jedna transakcia
sa zrusi (a druha moze pokracovat).
> > A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> > a komitnut aj druha transakcia.
>
> Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
> vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
> muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
> odvolana.
pozri ten moj priklad, tam to tak bezi
> > praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> > konfliktom pesimisticky ale optimisticky
>
> 1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
> soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
zial, nie vzdy. V uvedenom priklade to tak nebolo.
> > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
generaciach
> > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
vysvetli,
> > nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje
).
>
> Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
> verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
> obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
> obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
> retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
> kontext.
cize ak som to dobre pochopil, index obsahuje odkazy na rozne
generacie zaznamov a dodatocne je potrebne overit, ci ten zaznam
vybrany indexom je z tej mojej transakcie. Tu je potom este
otazka, ci sa nieco robi s indexom vtedy, ked transakcia zbehne,
resp. ked nezbehne. Teda ci sa ten index aktualizuje (napr. po
zbehnuti transakcie sa mozu IMHO v indexe zrusit odkazy
na stare generacie zaznamov, ktore boli transakciou prepisane).
alebo sa ponechava ako je a upratovanie indexov sa robi
dodatocne cez ten sweep (dufam, ze tak sa to v IB vola)
alebo priebeznym upratovanim.
> Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
> zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
> druhou stranu odpadaji jakekoliv hratky s indexem v pripade
> rollbacku, problemy synchronizace transakci na indexech apod. ktere
> postihuji systemy bez MGA.
takze pocas upratovania, ok
> Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
> soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
> "falesnych" kolizi.
lenze falosna kolizia ak sa zamok zisti vcas, nema iny dopad
ako pozdrzanie transakcie. Cize nemusi to byt vzdy nevyhodne.
V MDA je paralelizmus vecsi, ale zas to nemusi byt vzdy vyhodne.
V priklade, co som uviedol, nebola ziadna vyhoda paralelizmu,
prave naopak. U MDA mam taky nedobry pesimisticky pocit,
ze ked tam ten optimizmus nevyjde, tak sa situacia zacne
zhorsovat (pribuda smetie, vznikaju generacie zaznamov,
strata vykonu pocitaca v dosledku nezbehnutia transakcie).
A toho zhorsenie samotne moze sposobi dalsie zhorsenie
(nezbehnutu transakciu treba opakovat, mozno zbehne,
mozno zase nie, medzitym mozu byt spustene ine transakcie).
A takto sa to kumulovat.
> Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
> umeru mezi velikosti cache a ucinnosti cache, protoze:
>
> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> careful write dle orientovanych grafu zavislosti v ramci cache u
> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
>
> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> mechanizmus rizeni obsahu atd.)
uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
Pomer pristupovej doby disku a RAM-ky je asi milion, takze
to by musela byt poriadne komplikovana a neefektivna
sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
ze ta RAMka nieco stoji.
Erik
Odpovedá: Winsoft
19. 10. 2004 1:06
> cte existujici data. Pochop prosim, ze kdyz znas MS SQL a/nebo Oracle, tak
> to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line
zalohovani
> na MS SQL.
tak som si pozrel manual MS SQL 2000, ked to tu uz riesime. On-line
zalohovanie tam ma fungovat. A aspon v kratkosti este zopar informacii:
1. je tam niekolko typov backupov (napr. Database, Database differential,
Transaction log, File or file differential) a tri recovery modely: Simple,
Full, Bulk-Logged.
Co sa tyka vplyvu transakcii na zalohovanie, tak citujem
"Performing a
backup
operation has minimal effect on running transactions, so backup operations
can
be run during normal operations."
2. Co sa tyka restrikcii na backup, tak opet citujem (kompletne):
---------------------
Backup Restrictions
In Microsoft? SQL ServerT, backup operations can occur while the database is
online and in use. However, some operations are not allowed during a
database backup:
a.. Creating or deleting database files.
b.. The file truncation portion of a shrink operation on either the
database (automatically or manually) or the database files. They will fail
if a backup is running. You can perform the truncation after the backup
completes. For more information, see Shrinking a Database.
If a backup is started when one of these operations is in progress, the
backup waits for the operation to complete, up to the limit set by the
session timeout. If a backup is in progress and one of these operations is
attempted, the operation fails and the backup continues.
---------------------
3. A este zopar veci, ktore ma zaujali (je tam toho vela, presiel som to
len zbezne):
- Backup and Recovery of Related Databases (umoznuje urobit zalohu
dvoch alebo viacerych databaz, ktore musia byt logicky konzistentne)
- Partial Database Restore Operations (napr. ak aplikacia omylom
zrusila tabulku je mozne obnovit len tu cast databazy, ktora obsahovala
tabulku. Tiez sa to da pouzit na vytvorenie podmnoziny databazy
na inom serveri pre vyvojarske ucely alebo pre reporty)
- Restarting Interrupted Backup and Restore Operations (v pripade
ak backup alebo restore operacia je prerusena, napr. v dosledku
vypadku prudu, je mozne restartnut tu operaciu od bodu, v ktorom
doslo k peruseniu)
4. Dalej su tam rady ohladom Handling Large Mission-Critical
Environments, teda ako zvysit rychlost backup a restore operacii.
Erik
Odpovedá: Milan Tomes
19. 10. 2004 5:43
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 10:56 PM
>
> > Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
> > teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
> > zvolenou architekturu, to same co jsi napsal plati i pro system se
> > zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
> > zbytecne.
>
> tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
> z hladiska mozneho generovania zbytocneho smetia prejavi:
>
> Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
> transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
> su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
> ako T2):
>
> 1. Optimisticke zamykanie (MGA)
>
> Transakcia1 Transakcia2
>
> precita 'Erik' precita 'Erik'
> nieco robi zapise 'Patrik' (ako novu generaciu)
> nieco robi nieco robi
> nemoze zapisat 'Fero' nieco robi
> rollback commit
Opet nemas pravdu - i v MGA architekture se da transakci rici, ze ma cekat a
ne hned vyhodit chybu, nicmene tento priklad mi neprijde jako normalni a
bezny. Nicmene netvrdim, ze se nemuze stat. V praxi bude onen zapis spise
podminen nejakou podminkou. A i kdyby v tomto pripade nebyl tento priklad na
MGA rychlejsi, tak je milion dalsich, kdy tato architektura zrychleni
prinese. Napr.: proc by mela transakce 2 cekat na dokonceni transakce 1 kdyz
se jenom cetli zaznamy ??? Opravdu se neda tohle nejak pausalizovat.
A jak jiz psal P. Cisar - "smeti" se generuje jen pri zapisu a ten probehne
jen jeden - kde je tedy ono smeti na ktere neustale poukazujes ??? Ze by v
tom "nieco robi" ???
> Teda Transakcia2 zbehla ale Transkacia1 nie. To znamena,
> ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
> (v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
> tie zaznamy su nanic a teda vzniklo smetie. Cize Transakcia1
> bezala a zatazovala system zbytocne a okrem mozneho smetia,
> zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
> nic nevyriesila.
>
> 2. Pesimisticke zamykanie so zamkami
>
> Transakcia1 Transakcia2
>
> precita 'Erik' nemoze precitat (zamknute), tak caka
> nieco robi caka
> nieco robi caka
> zapise 'Fero' caka
> nieco robi caka
> commit odomknute, precita 'Fero'
> zapise 'Patrik'
> nieco robi
> nieco robi
> commit
A delka dobehnuti transakce 2 muze byt i nekolik dnu... No fuj...
Predpokladam, ze i pri pouziti pesimistickeho zamykani se muze transakci
rici - "v pripade konfliktu okamzite skonci". Zaroven me ale napada, ze
takovy system by byl v praxi vlastne nepouzitelny, protoze by transakce
predcasne koncili temer neustale... Dle mych zkusenosti probiha soucasne
cteni dost casto, ale samozrejme zalezi opet na programatorovi. Je nutno
prizpusobit zpusob programovani a vsechny transakce - i ty u kterych to neni
vyslovne potreba - musi byt dokonceny v co nejkratsim casovem intervalu coz
znamena pouziti nejakeho meziclanku ve forme MemoryDatasetu apod...
>
> Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni zamok.
> Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj komitnute.
>
> Aj v systeme so zamkami ale mozu vzniknut deadlocky a transakcia
> vtedy nezbehne (napr. ked sa zamknuty zaznam zisti neskoro a dovtedy
> samotna transakcia zamkla ine zaznamy).
>
> > > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
> >
> > 1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
> > zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
> > prvni pripad.
>
> MS SQL caka na odomknutie, pricom je mozne definovat timeout.
> Prednastavene je nekonecne cakanie. Samozrejme deadlocky
> sa detekuju, po ich zisteni sa uz necaka ale jedna transakcia
> sa zrusi (a druha moze pokracovat).
Proc opakujes to same, co psal P. Cisar ???
>
> > > A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> > > a komitnut aj druha transakcia.
> >
> > Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
> > vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
> > muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
> > odvolana.
>
> pozri ten moj priklad, tam to tak bezi
>
> > > praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> > > konfliktom pesimisticky ale optimisticky
> >
> > 1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
> > soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
>
> zial, nie vzdy. V uvedenom priklade to tak nebolo.
>
> > > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> generaciach
> > > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
> vysvetli,
> > > nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje
> ).
> >
> > Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
> > verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
> > obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
> > obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
> > retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
> > kontext.
>
> cize ak som to dobre pochopil, index obsahuje odkazy na rozne
> generacie zaznamov a dodatocne je potrebne overit, ci ten zaznam
> vybrany indexom je z tej mojej transakcie. Tu je potom este
> otazka, ci sa nieco robi s indexom vtedy, ked transakcia zbehne,
> resp. ked nezbehne. Teda ci sa ten index aktualizuje (napr. po
> zbehnuti transakcie sa mozu IMHO v indexe zrusit odkazy
> na stare generacie zaznamov, ktore boli transakciou prepisane).
> alebo sa ponechava ako je a upratovanie indexov sa robi
> dodatocne cez ten sweep (dufam, ze tak sa to v IB vola)
> alebo priebeznym upratovanim.
Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil - index
ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na jednu
strukturu a vybere se zaznam, ktery je v danem kontextu relevantni.
>
> > Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
> > zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
> > druhou stranu odpadaji jakekoliv hratky s indexem v pripade
> > rollbacku, problemy synchronizace transakci na indexech apod. ktere
> > postihuji systemy bez MGA.
>
> takze pocas upratovania, ok
>
> > Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
> > soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
> > "falesnych" kolizi.
>
> lenze falosna kolizia ak sa zamok zisti vcas, nema iny dopad
> ako pozdrzanie transakcie. Cize nemusi to byt vzdy nevyhodne.
Ja osobne to vidim jako naprosto tragickou nevyhodu. Co treba ukazes
uzivateli, ktery ceka na dokonceni operace ??? Neco jako
"Nezlobte se, ale
jiny uzivatel prave cte jakykoliv z milionu radku, ktery prave potrebujete
cist i Vy"
??? Pak si bude klepat na celo, protoze selsky rozum rika -
"proc
bych to nemohl cist take - vzdyt noviny si muze take cist nekolik lidi
naraz"...
A zase jsme u osobniho nazoru...
>
> V MDA je paralelizmus vecsi, ale zas to nemusi byt vzdy vyhodne.
> V priklade, co som uviedol, nebola ziadna vyhoda paralelizmu,
> prave naopak. U MDA mam taky nedobry pesimisticky pocit,
> ze ked tam ten optimizmus nevyjde, tak sa situacia zacne
> zhorsovat (pribuda smetie, vznikaju generacie zaznamov,
> strata vykonu pocitaca v dosledku nezbehnutia transakcie).
> A toho zhorsenie samotne moze sposobi dalsie zhorsenie
> (nezbehnutu transakciu treba opakovat, mozno zbehne,
> mozno zase nie, medzitym mozu byt spustene ine transakcie).
> A takto sa to kumulovat.
MGA Eriku - MGA.
Ted jsi na to kapl - je to jen o Tvem osobnim nazoru a Tvych pocitech. Jak
jiz psal P. Cisar - clovek, ktery vi, ze programuje nad MGA by mel zpusob
programovani prizpusobit prave teto okolnosti. Ja osobne s tim zadny vyrazny
problem nemam a to mi bezi v nekterych okamzicich i nekolik desitek
soucasnych transakci - ovsem jen jedna je R/W.
>
> > Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
> > umeru mezi velikosti cache a ucinnosti cache, protoze:
> >
> > 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> > careful write dle orientovanych grafu zavislosti v ramci cache u
> > kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
> >
> > 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> > mechanizmus rizeni obsahu atd.)
>
> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
> to by musela byt poriadne komplikovana a neefektivna
> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
> ze ta RAMka nieco stoji.
Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne ???
Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti opravdu nestaci a
je to jen jako hazet hrach na zed...
S pozdravem
Milan Tomes
Odpovedá: Karel Rys
19. 10. 2004 6:13
Winsoft dne 18 Oct 2004 v 16:17:
> a ako sa riesi zmena programu alebo databazy, ked dojde k zmene
> legislativy, alebo zmene struktury alebo fungovania podniku, alebo
> chyby v programe? To vsetko sa riesi za chodu systemu za plnej
> prevadzky?
Kvuli zmene struktury databaze je samozrejme nutne, aby s ni uzivatele v dany
moment nepracovali -
to vsak, se svym omezenym obzorem, povazuju za vicemene samozrejme u kazde
databaze, bez ohledu na
to, zda pouziva MGA nebo ne.
> Aky je to podnik, ze sa tam pracuje aj v nedelu a cez sviatky s
> informacnym systemom?
Neni to tak trochu jedno? Takove provozy proste jsou a mam s nimi co do
cineni, nicmene to sem
preci vubec nepatri!
Karel Rys
Odpovedá: Lstiburek Pavel
19. 10. 2004 7:35
On backup na MSSQL pracuje trochu sloziteji (nez jsem sam napsal),
backupovana nejsou jen data, ale i log. Do backupu jsou poslany vsechny
zaznamy bez ohledu na stav transkaci, ktera meni.
Pri restore jsou, ale vsechny nedokoncene nebo startu backup zahajene
operace odrolovany. Stejne tak je mozno i restorovat do libovolneho
okamziku v minulosti po startu backupu (az tam co mame k dispozici log).
To je i jeden z duvodu proc backup-restore nevede k zadne reoganizaci
DB, mam proste stejny srot jako pred touto operaci.
Stejne tak operace shrink jsou na vekych a zatizenych DB dost problematicke.
Log proste roste rychleji nez ho stacim sklepavat.
Provozuji DB o velikosti cca 2G a log staci vzhledem narust cca o 50-200M
denne, v zavislosti na zatizeni. Nutnost "seklepavat" log je jediny duvod proc
je DB prevadena 1x tydne do "dbo only" modu, aby mohl probehnout shrink.
Pavel
> From: Winsoft [mailto:winsoft@netkosice.sk]
> > cte existujici data. Pochop prosim, ze kdyz znas MS SQL
> a/nebo Oracle, tak
> > to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line
> zalohovani
> > na MS SQL.
>
> tak som si pozrel manual MS SQL 2000, ked to tu uz riesime. On-line
> zalohovanie tam ma fungovat. A aspon v kratkosti este zopar
> informacii:
>
> 1. je tam niekolko typov backupov (napr. Database, Database
> differential,
> Transaction log, File or file differential) a tri recovery
> modely: Simple,
> Full, Bulk-Logged.
>
> Co sa tyka vplyvu transakcii na zalohovanie, tak citujem
"Performing a
> backup
> operation has minimal effect on running transactions, so
> backup operations
> can
> be run during normal operations."
>
> 2. Co sa tyka restrikcii na backup, tak opet citujem (kompletne):
>
> ---------------------
>
> Backup Restrictions
> In Microsoft? SQL ServerT, backup operations can occur while
> the database is
> online and in use. However, some operations are not allowed during a
> database backup:
>
> a.. Creating or deleting database files.
>
> b.. The file truncation portion of a shrink operation on either the
> database (automatically or manually) or the database files.
> They will fail
> if a backup is running. You can perform the truncation after
> the backup
> completes. For more information, see Shrinking a Database.
>
> If a backup is started when one of these operations is in
> progress, the
> backup waits for the operation to complete, up to the limit set by the
> session timeout. If a backup is in progress and one of these
> operations is
> attempted, the operation fails and the backup continues.
>
> ---------------------
>
> 3. A este zopar veci, ktore ma zaujali (je tam toho vela,
> presiel som to
> len zbezne):
>
> - Backup and Recovery of Related Databases (umoznuje urobit zalohu
> dvoch alebo viacerych databaz, ktore musia byt logicky konzistentne)
>
> - Partial Database Restore Operations (napr. ak aplikacia omylom
> zrusila tabulku je mozne obnovit len tu cast databazy, ktora
> obsahovala
> tabulku. Tiez sa to da pouzit na vytvorenie podmnoziny databazy
> na inom serveri pre vyvojarske ucely alebo pre reporty)
>
> - Restarting Interrupted Backup and Restore Operations (v pripade
> ak backup alebo restore operacia je prerusena, napr. v dosledku
> vypadku prudu, je mozne restartnut tu operaciu od bodu, v ktorom
> doslo k peruseniu)
>
> 4. Dalej su tam rady ohladom Handling Large Mission-Critical
> Environments, teda ako zvysit rychlost backup a restore operacii.
>
>
Odpovedá: Stepan Dobias
19. 10. 2004 7:53
Pro Slavka - "CZ Strakonice, a.s (Vsude je FB a full backup kazdych 8
hodin.)"
. - je pro me prekvapeni, ze tam bezi zalohovani kazdych 8 hodin
kdyz jsem sam nastavoval zalohovani jednou denne. Pokud si dobre vzpominam
sam jsi tvrdil, ze zalohovani prilis zatezovalo system.
Pro priznivce Firebirdu :
Moc teda Firebird neznam, ale jak jsem pochopil z predchozich prispevkum P.
Cisare tak jsme nedelali nic blbe a on Backup a Restore skutecne trva tak
strasne dlouho. V porovnani s MS SQL 2000 asi tak 3 az 5 nasobek casu na
stejne velke DB (Pri Restore je rozdil jeste vyraznejsi). Jde to tedy na
vrub Multigeracni architektury (dle P. Cisare) a souhlasim s tim, ze pokud
to vyvojar vi tak se s tim dokaze vyrovnat.
Zalohovani:
Mohl by nekdo presne specifikovat proc by mel byt problem pri zalohovani MS
SQL 2000? My to provozujume kazdy den na zatizene DB a nemame s tim zatim
zadny problem (uz asi 3 rok). Odpoved bych ocenil od nekoho kdo ma
zkusenosti a ne od nekoho kdo neco nekde slysel od souseda. Rad se necham
poucit o moznych problemech.
S pozdravem
Stepan
Odpovedá: Petr Fejfar
19. 10. 2004 7:59
Milan Tomes wrote:
> probehne jen jeden - kde je tedy ono smeti na ktere neustale
> poukazujes ??? Ze by v tom "nieco robi" ???
Vzdyt ti to tam ES explicitne napsal:
<CITE>
To znamena, ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
(v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
</CITE>
> Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil -
> index ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na
> jednu strukturu a vybere se zaznam, ktery je v danem kontextu
> relevantni.
Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
fungovala,
tak se budou muset verzovat i indexy a PC odpovedel ze ne, ze se verzuji jen
radky.
Ale posleze doplnil, ze aby to fungovalo, tak uzel indexu obsahuje nekolik
ruznych klicu ke kazde zapsane hodnote.
A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem musi
udelat
ne zrovna lacina operace, i kdyz se ji zrovna nerika verzovani
>>> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
>>> careful write dle orientovanych grafu zavislosti v ramci cache u
>>> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
>>> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
>>> mechanizmus rizeni obsahu atd.)
>> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
>> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
>> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
>> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
>> to by musela byt poriadne komplikovana a neefektivna
>> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
>> ze ta RAMka nieco stoji.
>
> Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne
> ??? Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti
> opravdu nestaci a je to jen jako hazet hrach na zed...
Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
dob k mediim?
Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
cache u systemu, ktera by mohla pracovat hur nez system bez cache.
Ty o takovem systemu vis?
pf
Odpovedá: Richard Kejval
19. 10. 2004 8:13
> tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
> z hladiska mozneho generovania zbytocneho smetia prejavi:
>
> Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
> transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
> su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
> ako T2):
>
> 1. Optimisticke zamykanie (MGA)
>
> Transakcia1 Transakcia2
>
> precita 'Erik' precita 'Erik'
> nieco robi zapise 'Patrik' (ako novu generaciu)
> nieco robi nieco robi
> nemoze zapisat 'Fero' nieco robi
> rollback commit
>
Na tomto prikladu je jasne videt, ze si vubec nepochopil, nebo
nechces pochopit praci s transakcemi. Vzdyt Ti tam chybi uplne
zakladni predpoklad, s jakou urovni izolace jednotlive transakce
pristupuji k datum. Bez toho je to uplny blabol..
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware.cz
Odpovedá: Milan Tomes
19. 10. 2004 8:23
> -----Original Message-----
> From: delphi-l-owner@clexpert.cz
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Petr Fejfar
> Sent: Tuesday, October 19, 2004 8:59 AM
> To: delphi-l@clexpert.cz
> Subject: Re: Firebird a GBAK na velkou GDB
>
>
> Milan Tomes wrote:
>
> > probehne jen jeden - kde je tedy ono smeti na ktere neustale
> > poukazujes ??? Ze by v tom "nieco robi" ???
>
> Vzdyt ti to tam ES explicitne napsal:
>
> <CITE>
> To znamena, ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
> (v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
> </CITE>
>
>
> > Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil -
> > index ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na
> > jednu strukturu a vybere se zaznam, ktery je v danem kontextu
> > relevantni.
>
> Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
> fungovala,
> tak se budou muset verzovat i indexy a PC odpovedel ze ne, ze se
> verzuji jen
> radky.
> Ale posleze doplnil, ze aby to fungovalo, tak uzel indexu
> obsahuje nekolik
> ruznych klicu ke kazde zapsane hodnote.
>
> A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem musi
> udelat
> ne zrovna lacina operace, i kdyz se ji zrovna nerika verzovani
Jenze dle toho jak jsem to pochopil ja se s indexem jako takovym vubec nic v
okamziku vytvareni nove verze radku nic nedela. Do tabulky verzi radku se
zapise nova verze a index ukazuje na tu tabulku verzi - kde je tedy nejaka
operace *s indexem* ???
>
>
> >>> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> >>> careful write dle orientovanych grafu zavislosti v ramci cache u
> >>> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
> >>> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> >>> mechanizmus rizeni obsahu atd.)
> >> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
> >> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
> >> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
> >> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
> >> to by musela byt poriadne komplikovana a neefektivna
> >> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
> >> ze ta RAMka nieco stoji.
> >
> > Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne
> > ??? Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti
> > opravdu nestaci a je to jen jako hazet hrach na zed...
>
> Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
> a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
> dob k mediim?
>
> Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
> cache u systemu, ktera by mohla pracovat hur nez system bez cache.
> Ty o takovem systemu vis?
Ja netvrdim, ze existuje takovy system, ale pokud vezmu situaci, kdy
existuje cache jen pro cteni - a to je to o cem ES psal - tak mi pri
neustalem zapisu (rozumej pouze pri zapisu, kdy se neprovadi zadna operace
cteni) je k nicemu a navic me muze jeste zpomalit. Neber v potaz jakoukoliv
jinou cache nez tu, kterou ma databazovy stroj a kterou si take sam
spravuje. Je samozrejme - a to jsem take psal - ze cache sama o sobe
zrychluje pristup k jednotlivym zarizenim (at uz k RAM, HDD ci jinemu
zdroji), ale jsou situace kdy je vicemene zbytecna, protoze neprinasi zadne
zrychleni ba naopak jeji rezie prinasi zpomaleni.
Je samozrejme, ze i cache pro cteni casto zpomaluje, ale pokud si vezmeme
pomer mezi zpomalenim a zrychlenim, tak se dostavame napr. do cisel 1:1000 a
pak se samozrejme ono zpomaleni - zcela logicky - vynecha.
Takze vezmeme nasledujici situaci:
HDD s cache, CPU s cache, SQL server s cache (pro cteni - pro zapis je
vypnuta) a ja budu jen a jen zapisovat. K cemu je mi cache pro cteni ??? K
nicemu a jeste bude probihat thread, ktery se stara o jeji spravu i kdyz ji
v dany okamzik nepotrebuji. Toto jsem mel na mysli. Je samozrejme, ze se
vetsinou nejaka operace cteni vyskytne, ale pri zapisu by me tato cache
pouze obtezovala.
Jinak se ES omlouvam za osobni utok, ale opravdu me rozciluji lide, kteri
MUSI mit za kazdou cenu pravdu a nejsou ochotni prijmout argumenty jinych.
Jeste bych rad zareagoval na onen puvodni vyrok Erika:
<CITE>
uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
Pomer pristupovej doby disku a RAM-ky je asi milion, takze
to by musela byt poriadne komplikovana a neefektivna
sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
ze ta RAMka nieco stoji.
</CITE>
Ano - pokud zvetsis pamet RAM, tak se nepochybne i zvysi spotreba strojoveho
casu na jeji obnovu (nezapominej, ze se jedna o dynamicke pameti RAM a musi
se neustale obnovovat - tusim, ze kdysi se to cislo pohybovalo nekde okolo
4ms), ale jeji prinos je vyvazen mensim vyuzitim strankovaciho souboru -
samozrejme v pripade pouziti Windows - a tudiz je pridani RAM vnimano jako
zrychleni. Odmysli si vsak operacni system a mer cas procesoru, ktery se
stravi vlastnim refreshem obsahu pameti a uvidis...
S pozdravem
Milan Tomes
Odpovedá: Pavel Cisar
19. 10. 2004 10:53
Haj hou!
On 19 Oct 2004 at 8:59, Petr Fejfar wrote:
> Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
> fungovala, tak se budou muset verzovat i indexy a PC odpovedel ze ne,
> ze se verzuji jen radky. Ale posleze doplnil, ze aby to fungovalo, tak
> uzel indexu obsahuje nekolik ruznych klicu ke kazde zapsane hodnote.
>
> A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem
> musi udelat ne zrovna lacina operace, i kdyz se ji zrovna nerika
> verzovani
Omyl, napsal jsem, ze uzel indexu obsahuje pouze jedinou hodnotu
klice a odkaz na radek, a ze muze existovat vice *uzlu* s ruznou
hodnotou klice, ktere odkazuji na stejny radek, resp. retez verzi
tohoto radku. Relevance nalezeneho uzlu / klice se vyhodnocuje pres
radek a jeho retez verzi pro dany transakcni kontext.
> Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
> a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
> dob k mediim?
>
> Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
> cache u systemu, ktera by mohla pracovat hur nez system bez cache.
> Ty o takovem systemu vis?
O tom jsem uz preci psal ja. Vubec totiz nejde o pristupovou dobu do
cache jak to vidi Erik, ale o uspesnost vyuziti cache, tedy zda jsou
data ctena z cache misto z disku. Zvetseni velikosti cache
automaticky neznamena zvyseni uspesnosti jejiho vyuziti (pominme
extremni pripad, kdy se cela databaze vejde do cache). Zalezi na
charakteristikach pristupu k datum (nahodny, sekvencni, frekvence,
lokalizace atd.) a mechanizmu rizeni obsahu cache. Ale to je jen
pulka problemu - cteni dat, samostatnou kapitolou je zapis skrz
cache.
Cache databazovych systemu se vyrazne lisi od zpusobu prace cache
napr. v operacnim systemu pro soubory na disku, nebo v CPU pro
instrukce. U Databazi existuje rada struktur zapisovanych odddelene
ktere jsou ale na sobe zavisle, a je nutne je zapisovat v presnem
konkretnim poradi, aby v pripade nedokonceneho zapisu (napr. z duvodu
vypadku proudu) nedoslo k poskozeni dat. Napr. u Firebirdu existuji
tzv. Pointer Pages (PP), ktere obsahuji mapu Datovych stranek (DP)
prirazenych dane tabulce. V pripade ulozeni dat do nove datove
stranky je treba aktualizovat a zapsat i prislusnou Pointer stranku.
Pokud by poradi bylo PP a pak DP, a k zapisu DP by z nejakeho duvodu
nedoslo, obsahovala by databaze odkaz (v PP) na neulozenou, a tedy
obsahove chybnou stranku. Po restartu by server pri pokusu o pristup
k teto datove strance vyhucel s chybou, a to dost natvrdo, protoze
integrita databaze je v haji. Pri zapisu v poradi DP a pak PP, pokud
k zapisu PP nedojde, bude databaze obsahovat DP na kterou se nelze
dostat (neodkazuje na ni PP), coz je sice nehezke, ale nedojde k
zadne chybe pri praci s databazi. Ona nedostupna DP stejne obsahuje
pouze nove vytvorena nepotvrzena data urcena k odstraneni. Podstatne
je, ze vnitrni integrita databaze neni narusena.
Vyse uvedenemu postupu se rika careful write, a je pro databazovy
system velmi dulezity. Pro menene stranky jejichz zapis je odlozen
(jsou v cache) je tedy nutne uchovavat orientovany graf zavislosti,
aby pak pri zapisu z cache na disk bylo dodrzeno poradi zapisu.
Slozitost struktury pro rizeni cache a careful write typicky roste s
velikosti cache (vyhledavani stranek v cache, grafy zavislosti),
proto muze byt prace s mensi cache rychlejsi nez s velkou cache.
Optimalni velikost cache je ruzna podle velikosti databaze,
charakteru dat a charakteru prace s nimi. Je nutne ji posuzovat a
nastavovat individualne, a plati to pro kazdy databazovy system.
Tohle myslim potvrdi kazdy zkuseny DBA.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Petr Fejfar
19. 10. 2004 11:10
Pavel Cisar wrote:
> O tom jsem uz preci psal ja. Vubec totiz nejde o pristupovou dobu do
> cache jak to vidi Erik, ale o uspesnost vyuziti cache, tedy zda jsou
> data ctena z cache misto z disku. Zvetseni velikosti cache
> automaticky neznamena zvyseni uspesnosti jejiho vyuziti
Mimo spekulativni pripady pravdepodobnost, ze se data budou cist z cache
misto z disku urcite s velikosti cache poroste - ostatne jak sam pises,
v pripade, ze se cela DB vejde do cache, dosahnes jistoty
Jina otazka je samozrejme o kolik. Proto si myslim, ze pomer pristupovych
dob je *urcujicim* kriteriem, mj. to jsou zmeritelne veliciny, zatimco
ostatni vlastnosti jak se o nich zminujes jsou z kategorie heuristik,
odhadu a predpokladu.
> Optimalni velikost cache je ruzna ....
Ano, ale optimum prece neznamena, ze se efektivita cache nezvysuje
spolu s velikosti pameti. Jen se to nad nejakou mez nevyplati popr. je to
nerealizovatelne.
pf
Odpovedá: Pavel Cisar
19. 10. 2004 11:05
Haj hou!
On 18 Oct 2004 at 22:56, Winsoft wrote:
> tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
> z hladiska mozneho generovania zbytocneho smetia prejavi:
Ok, podivejme se tedy na ne.
> Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
> transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
> su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
> ako T2):
>
> 1. Optimisticke zamykanie (MGA)
>
> Transakcia1 Transakcia2
>
> precita 'Erik' precita 'Erik'
> nieco robi zapise 'Patrik' (ako novu generaciu)
> nieco robi nieco robi
> nemoze zapisat 'Fero' nieco robi
> rollback commit
Tento priklad je sice po formalni strance vporadku, nicmene postrada
vyznamny udaj: v jake urovni izolace obe transakce pracuji, a jake
maji dalsi parametry.
Uvedeny priklad bude pravdivy pouze pokud T1 bude v rezimu NOWAIT
(implicitni je ovsem WAIT), a ani jedna z obou transakci nebude v
izolaci Snapshot table stability, pripadne nebude vyuzivat rezervace
tabulek pro danou tabulku (pak muze byt i v jine urovni izolace). Pri
jinem nastaveni parametru bude chovani odlisne.
> Teda Transakcia2 zbehla ale Transkacia1 nie. To znamena,
> ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
> (v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
> tie zaznamy su nanic a teda vzniklo smetie. Cize Transakcia1
> bezala a zatazovala system zbytocne a okrem mozneho smetia,
> zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
> nic nevyriesila.
Pominme pravzlastni logiku tvrzeni, ze (cituji):
"Cize Transakcia1
bezala a zatazovala system zbytocne a okrem mozneho smetia,
zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
nic nevyriesila.".
Toto tvrzeni lze totiz aplikovat na jakoukoliv
transakci ktera z nejakeho duvodu skoncila rollbackem, a to bez
ohledu na architekturu transakci. Venujme se tedy zbytku tvrzeni
ktere se tyka "smeti" vytvorenemu v T1.
Mas pravdu jen castecne. Mas pravdu v tom, ze verze radku vytvorene
T1 jsou po jejim rollbacku jiz zbytecne.Jenze ty porad vnimas dany
problem pouze z uzkeho hlediska situace vznikle po rollbacku T1. Pred
timto okamzikem *nejsou* verze vytvorene touto transakci zbytecne,
ale primo nezbytne. Rovnez nemas pravdu v pripade zbytecneho
zatezovani systemu z duvodu zbytecneho vytvareni verzi radku.
Puvodni hodnota radku *musi* byt nekde uchovana, bud primo v databazi
jako u MGA, nebo v transakcnim logu. Ty vnimas vytvoreni nove verze
radku jako neco specifickeho pro MGA, ale neni to pravda. I system s
logem zapisuje primo do databaze *novou verzi radku*. Rozdil je v
tom, co se deje s *puvodni verzi radku*. U MGA zustava v databazi, u
systemu s logem skonci v logu. Mnozstvi prace a dat zpracovane pri
zapisu je tedy u MGA a systemu s logem v podstate stejne. Jediny
rozdil je v tom, ze po rollbacku je u MGA zbytecna novejsi verze, a
po commitu naopak starsi verze. U systemu s logem se jedna vzdy pouze
o puvodni hodnotu radku (je v logu), a ta se rovnez stava zbytecnou,
a to jak po rollbacku, tak i po commitu. Po rollbacku je navic nutne
obnovit hodnotu radku v databazi. Dle tve logiky (viz citace vyse) by
se tedy rovnez dalo prohlasit, ze jedna z transakci vygenerovala data
zbytecne, a to bez ohledu na architekturu. Nicmene to ani v jednom
pripade nebyla zbytecna prace, protoze se ji proste uz z podstaty
transakci vyhnout neda.
Podivejme se ted na stejny priklad, ale z pohledu systemu se zamky a
logem. On je totiz aplikovatelny i na tento system Zapis radku v
T2 totiz na radek uvali zamek, a T1 jej tedy nemuze prepsat (a v jine
izolaci nez Read Uncommitted, cili Dirty Read dokonce ani cist, coz
by s MGA mohla), a pokud bude v rezimu NOWAIT vyhuci naprosto stejne
jako v uvedenem prikladu. Pokud bude v rezimu WAIT, pak ma rovnez
sanci skoncit s chybou, a to naprosto stejnou jako u systemu s MGA.
Predpokladejme, ze skonci s chybou (z prikladu neni az tak patrna
casova souslednost, ale po commitu T2 musi T1 skoncit s chybou).
Pri rollbacku T1 je nutne projit transakcni log, a obnovit puvodni
hodnoty radku ktere T1 zmenila (predpokladam, ze neco zmenila. Ty
pises ze pred kolizi "nieco robi", coz muze byt i pouhe cteni,
nicmene z dalsiho textu se da usuzovat ze neco menila). U MGA se nic
takoveho nedeje. Rozdil mezi nulovou praci (u MGA) a nejakou praci
(obnova z logu) mi vychazi jednoznacne ve prospech MGA. Pokud tedy T1
zbytecne mari nejake zdroje, pak je to u systemu s transakcnim logem
(opet pripominam, ze praci spojene s uchovanim puvodni hodnoty radku
se vyhnout neda za zadnych okolnosti).
> 2. Pesimisticke zamykanie so zamkami
>
> Transakcia1 Transakcia2
>
> precita 'Erik' nemoze precitat (zamknute), tak caka
> nieco robi caka
> nieco robi caka
> zapise 'Fero' caka
> nieco robi caka
> commit odomknute, precita 'Fero'
> zapise 'Patrik'
> nieco robi
> nieco robi
> commit
Eriku, opravdu myslis uvedeny priklad vazne ? Jeste jsem nevidel
viceuzivatelsky (ale ani jiny) system, kde by cteni dat v jedne
transakci znemoznovalo cist stejna data v jine transakci. Pokud jsi
vyseuvedeny priklad myslel smrtelne vazne a seriozne, pak jsi
prokazal elementarni neznalost problematiky transakci, a rizeni
pristupu k sdilenym zdrojum v databazovych (ale i jinych) systemech.
> Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni
> zamok. Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj
> komitnute.
Protoze je uvedeny priklad naprosto nesmyslny, nema smysl rozebirat
zavery ktere z neho vyvozujes.
> cize ak som to dobre pochopil, index obsahuje odkazy na rozne
> generacie zaznamov a dodatocne je potrebne overit, ci ten zaznam
> vybrany indexom je z tej mojej transakcie.
Tohle jsem vysvetloval uz v jinem mailu. Ve zkratce: Ne (nikoliv na
rizne verze, ale na cely retez) a Ano (relevanci nutno overit z dat
radku).
> Tu je potom este otazka, ci sa nieco robi s indexom vtedy, ked
> transakcia zbehne, resp. ked nezbehne. Teda ci sa ten index aktualizuje
> (napr. po zbehnuti transakcie sa mozu IMHO v indexe zrusit odkazy na
> stare generacie zaznamov, ktore boli transakciou prepisane). alebo sa
> ponechava ako je a upratovanie indexov sa robi dodatocne cez ten sweep
> (dufam, ze tak sa to v IB vola) alebo priebeznym upratovanim.
V ramci transakce (resp. jejiho ukonceni) se pokud vim s indexem
nedeje nic (bude obsahovat jiz neplatny uzel). Struktura indexu se
urcite cisti pri sweepu, a za urcitych okolnosti i pri GC, ale na
podrobnosti si ted nevzpomenu.
> lenze falosna kolizia ak sa zamok zisti vcas, nema iny dopad
> ako pozdrzanie transakcie. Cize nemusi to byt vzdy nevyhodne.
To mi prijde naopak jako velmi nevyhodne. Falesna kolize je falesna
kolize, k tem by vubec nikdy nemelo dojit.
> V MDA je paralelizmus vecsi, ale zas to nemusi byt vzdy vyhodne. V
> priklade, co som uviedol, nebola ziadna vyhoda paralelizmu, prave
> naopak.
Priklad byl nesmyslny. Z nesmyslnych predpokladu se jen malokdy daji
vytvorit smysluplne zavery.
> U MDA mam taky nedobry pesimisticky pocit, ze ked tam ten optimizmus
> nevyjde, tak sa situacia zacne zhorsovat (pribuda smetie, vznikaju
> generacie zaznamov, strata vykonu pocitaca v dosledku nezbehnutia
> transakcie).
1. Osobni pocity nemaji nic spolecneho s objektivni realitou.
2. Smeti, tedy jiz bytecne verze radku vznikaji s kazdym koncem
transakce, bez ohledu zda jde o rollback nebo commit. MGA ma
mechanizmy, jak se jich zbavovat a udrzet jejich mnozstvi na uzde
(pokud ovsem vyvojar nenasadi vsechny paky aby ji praci stizil nebo
znemoznil).
> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
> to by musela byt poriadne komplikovana a neefektivna
> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
> ze ta RAMka nieco stoji.
K tomuhle jsem se vyjadril v jinem mailu.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Winsoft
19. 10. 2004 11:47
> > 1. Optimisticke zamykanie (MGA)
> >
> > Transakcia1 Transakcia2
> >
> > precita 'Erik' precita 'Erik'
> > nieco robi zapise 'Patrik' (ako novu generaciu)
> > nieco robi nieco robi
> > nemoze zapisat 'Fero' nieco robi
> > rollback commit
>
> Tento priklad je sice po formalni strance vporadku, nicmene postrada
> vyznamny udaj: v jake urovni izolace obe transakce pracuji, a jake
> maji dalsi parametry.
myslim, ze sa tu uz dost dlho o tom bavime a vysvetlujeme ako co
kedy sa robi, aby bolo kazdemu jasne o aku uroven izolacie ide.
Nevyhovaraj sa prosim, ale ries problem a hovor k veci.
> Uvedeny priklad bude pravdivy pouze pokud T1 bude v rezimu NOWAIT
> (implicitni je ovsem WAIT), a ani jedna z obou transakci nebude v
> izolaci Snapshot table stability, pripadne nebude vyuzivat rezervace
> tabulek pro danou tabulku (pak muze byt i v jine urovni izolace). Pri
> jinem nastaveni parametru bude chovani odlisne.
no skus mi vysvetlit, v com bude vyhoda ak T1 namiesto rollback
bude cakat. To len este zhorsi situaciu. T1 bude zbytocne cakat,
jednoducho nemoze prepisat uz prepisany zaznam ani po skonceni
T2 nech by cakal akokolvek dlho.
> Pominme pravzlastni logiku tvrzeni, ze (cituji):
"Cize Transakcia1
> bezala a zatazovala system zbytocne a okrem mozneho smetia,
> zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
> nic nevyriesila.".
Toto tvrzeni lze totiz aplikovat na jakoukoliv
> transakci ktera z nejakeho duvodu skoncila rollbackem, a to bez
> ohledu na architekturu transakci. Venujme se tedy zbytku tvrzeni
> ktere se tyka "smeti" vytvorenemu v T1.
ta logika je v tom, ze v jednom z tych systemov v rovnakom priklade
ta transakcia zbehla a nebola zbytocna. Takze to je IMHO rozdiel.
> Podivejme se ted na stejny priklad, ale z pohledu systemu se zamky a
> logem. On je totiz aplikovatelny i na tento system Zapis radku v
> T2 totiz na radek uvali zamek, a T1 jej tedy nemuze prepsat (a v jine
> izolaci nez Read Uncommitted, cili Dirty Read dokonce ani cist, coz
> by s MGA mohla), a pokud bude v rezimu NOWAIT vyhuci naprosto stejne
> jako v uvedenem prikladu. Pokud bude v rezimu WAIT, pak ma rovnez
> sanci skoncit s chybou, a to naprosto stejnou jako u systemu s MGA.
> Predpokladejme, ze skonci s chybou (z prikladu neni az tak patrna
> casova souslednost, ale po commitu T2 musi T1 skoncit s chybou).
Lenze T1 moze normalne komitnut po T2 presne ako som to uviedol.
A v MGA nemoze. Takze zbytocne sa vyhovarat, v tomto pripade
je to jednoducho tak. Mozes to hoci aj vedecky dokazat alebo vyvratit.
> Eriku, opravdu myslis uvedeny priklad vazne ? Jeste jsem nevidel
> viceuzivatelsky (ale ani jiny) system, kde by cteni dat v jedne
> transakci znemoznovalo cist stejna data v jine transakci. Pokud jsi
> vyseuvedeny priklad myslel smrtelne vazne a seriozne, pak jsi
> prokazal elementarni neznalost problematiky transakci, a rizeni
> pristupu k sdilenym zdrojum v databazovych (ale i jinych) systemech.
takze jedina spravna a univerzalna uroven je zrejme ten snaphot
a tomu treba vsetko dopasovat. A tam, kde to nevelmi pasuje
radsej napadame protivnika z naznalosti elementarnej problematiky.
> > Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni
> > zamok. Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj
> > komitnute.
>
> Protoze je uvedeny priklad naprosto nesmyslny, nema smysl rozebirat
> zavery ktere z neho vyvozujes.
lebo nam nepasuje, tak sa mu vyhnime. Este k tomu napis, ze je to
vedecky dokazane, ze je to naprosto nezmyselny a vec je pre Teba
zrejme vybavena. Prepac, ale ja to nemozem inak komentovat a tato
diskusia tak uplne stratila akykolvek vyznam.
Erik
Odpovedá: Milan Tomes
19. 10. 2004 12:05
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Tuesday, October 19, 2004 12:48 PM
>
> > Podivejme se ted na stejny priklad, ale z pohledu systemu se zamky a
> > logem. On je totiz aplikovatelny i na tento system Zapis radku v
> > T2 totiz na radek uvali zamek, a T1 jej tedy nemuze prepsat (a v jine
> > izolaci nez Read Uncommitted, cili Dirty Read dokonce ani cist, coz
> > by s MGA mohla), a pokud bude v rezimu NOWAIT vyhuci naprosto stejne
> > jako v uvedenem prikladu. Pokud bude v rezimu WAIT, pak ma rovnez
> > sanci skoncit s chybou, a to naprosto stejnou jako u systemu s MGA.
> > Predpokladejme, ze skonci s chybou (z prikladu neni az tak patrna
> > casova souslednost, ale po commitu T2 musi T1 skoncit s chybou).
>
> Lenze T1 moze normalne komitnut po T2 presne ako som to uviedol.
> A v MGA nemoze. Takze zbytocne sa vyhovarat, v tomto pripade
> je to jednoducho tak. Mozes to hoci aj vedecky dokazat alebo vyvratit.
Osobne si myslim, ze se commit povest NESMI. Uz jen z jednoho prosteho
duvodu - data by se mohla stat nekonzistentnimi, protoze v dobe zahajeni
transakce bylo vse jinak a soucasny stav se od vychoziho stavu odlisuje a
muze byt tedy ovlivnena i relevantnost takove transakce. A v tu chvili se
Tve argumenty stavaji irelevantnimi.
> > Eriku, opravdu myslis uvedeny priklad vazne ? Jeste jsem nevidel
> > viceuzivatelsky (ale ani jiny) system, kde by cteni dat v jedne
> > transakci znemoznovalo cist stejna data v jine transakci. Pokud jsi
> > vyseuvedeny priklad myslel smrtelne vazne a seriozne, pak jsi
> > prokazal elementarni neznalost problematiky transakci, a rizeni
> > pristupu k sdilenym zdrojum v databazovych (ale i jinych) systemech.
>
> takze jedina spravna a univerzalna uroven je zrejme ten snaphot
> a tomu treba vsetko dopasovat. A tam, kde to nevelmi pasuje
> radsej napadame protivnika z naznalosti elementarnej problematiky.
Ale to preci neni o Snapshot transakci. Tohle je o Read commited a i v tuto
chvili to proste nejde ani precist. A to je neco co ja proste nehodlam
prekousnout. A spokojit se s Dirty read ??? NIKDY - konzistence dat je pro
me az prilis dulezita. Snapshot je o necem naprosto jinem nez je Read
commited a uz uplne neco jineho nez o cem pises Ty.
>
> > > Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni
> > > zamok. Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj
> > > komitnute.
> >
> > Protoze je uvedeny priklad naprosto nesmyslny, nema smysl rozebirat
> > zavery ktere z neho vyvozujes.
>
> lebo nam nepasuje, tak sa mu vyhnime. Este k tomu napis, ze je to
> vedecky dokazane, ze je to naprosto nezmyselny a vec je pre Teba
> zrejme vybavena. Prepac, ale ja to nemozem inak komentovat a tato
> diskusia tak uplne stratila akykolvek vyznam.
A proc Ty tedy argumenty nedokazes relevantnost Tebou uvedeneho prikladu. Ja
jej totiz taky s odstupem casu povazuji za v praxi naprosto nepouzitelny a
tudiz irelevantni.
S pozdravem
Milan Tomes
Odpovedá: Pavel Cisar
19. 10. 2004 12:54
Haj hou!
On 19 Oct 2004 at 12:47, Winsoft wrote:
> > Uvedeny priklad bude pravdivy pouze pokud T1 bude v rezimu NOWAIT
> > (implicitni je ovsem WAIT), a ani jedna z obou transakci nebude v
> > izolaci Snapshot table stability, pripadne nebude vyuzivat rezervace
> > tabulek pro danou tabulku (pak muze byt i v jine urovni izolace). Pri
> > jinem nastaveni parametru bude chovani odlisne.
>
> no skus mi vysvetlit, v com bude vyhoda ak T1 namiesto rollback
> bude cakat. To len este zhorsi situaciu.
Protoze velmi casta reakce aplikace na selhani transakce je opakovani
operace v nove transakci, muze cekani na konec T2 situaci naopak
zlepsit, protoze nemuze dojit k fenomenu zvanemu "live lock". Frontu
pozadavku na zdroj v tomto pripade ridi server, ktery ma o situaci
nejvetsi prehled, nikoliv aplikace ktera vi o situaci "na bojisti"
velky kulovy.
> T1 bude zbytocne cakat, jednoducho nemoze prepisat uz prepisany zaznam
> ani po skonceni T2 nech by cakal akokolvek dlho.
Nebude zbytecne cekat, pokud T2 nebude potvrzena, ale skonci
rollbackem. Pak muze klidne svou zmenu zapsat. Ty jsi sice v prikladu
rozhodl ze T2 skonci commitem, a T1 tedy musi obdrzet chybu, ale v
dobe detekce kolize jeste o vysledku T2 neni rozhodnuto, a cekani by
tedy mohlo mit smysl. A i v pripade neuspechu cekani se muze
vyplatit, viz vyse o live locku.
> > Podivejme se ted na stejny priklad, ale z pohledu systemu se zamky a
> > logem. On je totiz aplikovatelny i na tento system Zapis radku v
> > T2 totiz na radek uvali zamek, a T1 jej tedy nemuze prepsat (a v jine
> > izolaci nez Read Uncommitted, cili Dirty Read dokonce ani cist, coz
> > by s MGA mohla), a pokud bude v rezimu NOWAIT vyhuci naprosto stejne
> > jako v uvedenem prikladu. Pokud bude v rezimu WAIT, pak ma rovnez
> > sanci skoncit s chybou, a to naprosto stejnou jako u systemu s MGA.
> > Predpokladejme, ze skonci s chybou (z prikladu neni az tak patrna
> > casova souslednost, ale po commitu T2 musi T1 skoncit s chybou).
>
> Lenze T1 moze normalne komitnut po T2 presne ako som to uviedol.
> A v MGA nemoze. Takze zbytocne sa vyhovarat, v tomto pripade
> je to jednoducho tak. Mozes to hoci aj vedecky dokazat alebo vyvratit.
ROFL
> > Eriku, opravdu myslis uvedeny priklad vazne ? Jeste jsem nevidel
> > viceuzivatelsky (ale ani jiny) system, kde by cteni dat v jedne
> > transakci znemoznovalo cist stejna data v jine transakci. Pokud jsi
> > vyseuvedeny priklad myslel smrtelne vazne a seriozne, pak jsi
> > prokazal elementarni neznalost problematiky transakci, a rizeni
> > pristupu k sdilenym zdrojum v databazovych (ale i jinych) systemech.
>
> takze jedina spravna a univerzalna uroven je zrejme ten snaphot
> a tomu treba vsetko dopasovat. A tam, kde to nevelmi pasuje
> radsej napadame protivnika z naznalosti elementarnej problematiky.
Tohle preci s urovni izolace nema vubec nic spolecneho, dokonce ani
specificky s databazemi. Proc radsi jako chlap nepriznas, ze jsi
placnul naprosty blabol ? A postavit priklad (natoz pak dukazni) na
naprosto nesmyslnem premise ze cteni by melo blokovat jine cteni neni
nic jineho nez blabol, at uz se na to podivas z kterekoliv strany.
> > > Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni
> > > zamok. Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj
> > > komitnute.
> >
> > Protoze je uvedeny priklad naprosto nesmyslny, nema smysl rozebirat
> > zavery ktere z neho vyvozujes.
>
> lebo nam nepasuje, tak sa mu vyhnime. Este k tomu napis, ze je to
> vedecky dokazane, ze je to naprosto nezmyselny a vec je pre Teba
> zrejme vybavena. Prepac, ale ja to nemozem inak komentovat a tato
> diskusia tak uplne stratila akykolvek vyznam.
Pro me osobne diskuze s tebou stratily vyznam uz davno A pentli
si tu cancam spis kvuli intelektualnimu cviceni ve formulaci
argumentu a kvuli ostatnim v konferenci, nez kvuli tobe.
Nicmene pokud predlozis nejakou dukazni konstrukci na prikladu se
zamky, ktera nebude postavena na nesmyslne premise ze cteni blokuje
jine cteni, muzeme v ni nadale pokracovat.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Slavomir Skopalik
19. 10. 2004 13:31
> Pro Slavka -
"CZ Strakonice, a.s (Vsude je FB a full backup
> kazdych 8 hodin.)" . - je
pro me prekvapeni, ze tam bezi
> zalohovani kazdych 8 hodin kdyz jsem sam nastavoval
> zalohovani jednou denne. Pokud si dobre vzpominam sam jsi
> tvrdil, ze zalohovani prilis zatezovalo system.
Pardon, bezelo, dokud "nekdo" neprovedl neodborne nastaveni serveru.
Zalohovani tam ted trva priblizne 2:30 (ano dve hodiny a tricet minut),
pod linuxem trvalo na historickem 2.2 kernelu a RaiserFS 1.0 cca 30
minut.
Ted bezi zalohovani jednou denne.
Problem je spatne nastavene diskove pole + spatne nastaveni zalohovani
(staci behem zalohovani sledovat CPU, dojde totiz k vytreshovani
vsech diskovych cache, CPU se pohybuje okolo 10 - 25%).
Reseni:
1. Vyhrazeny disk pro tempy (mel by byt RAID1)
2. Pouziti presmerovani vystupu do vstupu druheho programu (pipe).
3. Pouziti aplikacniho serveru na zalohovani
Slavek
Ing. Slavomir Skopalik
Jednatel spolecnosti
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
--------------------------------------------
Mobil: +420 724 207 851
icq:199 118 333
e-mail:skopalik@elektlabs.cz
http://www.elektlabs.cz
Odpovedá: Stepan Dobias
19. 10. 2004 14:11
Asi to sem nepatri a nehodlam se k tomu nijak siroce vyjadrovat. Jen bych te
rad upozornil, ze tebou navrhovana reseni uz jsme diskutovali a nebylo to
uplne, tak jak tvrdis, napr. v dokumentaci jsem nasel, ze "pipe" funguji v
FB1.0 pouze na linuxu. Dale je zvlastni ze do provedeni tvych uprav bezelo
zalohovani i na Windows 30 min.
Samozrejme nevylucuji, ze jsme neudelali chybu. Jen je zvlastni, ze
zalohovani DB dalsich firem probiha celkem bez problemu a blbne jen ta
tvoje.
Stepan
----- Original Message -----
From: "Slavomir Skopalik" <skopalik@elektlabs.cz>
To: <delphi-l@clexpert.cz>
Sent: Tuesday, October 19, 2004 2:31 PM
Subject: Re: Firebird a GBAK na velkou GDB
> > Pro Slavka -
"CZ Strakonice, a.s (Vsude je FB a full backup
> > kazdych 8 hodin.)" . - je
pro me prekvapeni, ze tam bezi
> > zalohovani kazdych 8 hodin kdyz jsem sam nastavoval
> > zalohovani jednou denne. Pokud si dobre vzpominam sam jsi
> > tvrdil, ze zalohovani prilis zatezovalo system.
>
> Pardon, bezelo, dokud "nekdo" neprovedl neodborne nastaveni serveru.
> Zalohovani tam ted trva priblizne 2:30 (ano dve hodiny a tricet minut),
> pod linuxem trvalo na historickem 2.2 kernelu a RaiserFS 1.0 cca 30
> minut.
>
> Ted bezi zalohovani jednou denne.
>
> Problem je spatne nastavene diskove pole + spatne nastaveni zalohovani
> (staci behem zalohovani sledovat CPU, dojde totiz k vytreshovani
> vsech diskovych cache, CPU se pohybuje okolo 10 - 25%).
>
> Reseni:
> 1. Vyhrazeny disk pro tempy (mel by byt RAID1)
> 2. Pouziti presmerovani vystupu do vstupu druheho programu (pipe).
> 3. Pouziti aplikacniho serveru na zalohovani
>
> Slavek
>
> Ing. Slavomir Skopalik
> Jednatel spolecnosti
> Elekt Labs s.r.o.
> Chaloupky 158
> 783 72 Velky Tynec
> Czech Republic
> --------------------------------------------
> Mobil: +420 724 207 851
> icq:199 118 333
> e-mail:skopalik@elektlabs.cz
> http://www.elektlabs.cz
>
>
>
>
Odpovedá: Winsoft
19. 10. 2004 14:10
> Nebude zbytecne cekat, pokud T2 nebude potvrzena, ale skonci
> rollbackem. Pak muze klidne svou zmenu zapsat. Ty jsi sice v prikladu
> rozhodl ze T2 skonci commitem, a T1 tedy musi obdrzet chybu, ale v
> dobe detekce kolize jeste o vysledku T2 neni rozhodnuto, a cekani by
> tedy mohlo mit smysl. A i v pripade neuspechu cekani se muze
> vyplatit, viz vyse o live locku.
prepac, ale zas si to nedospekuloval, zas len komitne jedna
transakcia, akurat, ze ta druha. Mne komitli obidva.
Erik
Odpovedá: Ludek ZITA
19. 10. 2004 14:17
On Behalf Of Winsoft
]
> aha, takze Microsoft a Oracle si nemozu ekonomicky dovolit
> implementovat MGA. Na rozdiel od akejsi firmicky (neviem si
> teraz spomenut ako sa vlastne vola), ktora robi MySQL.
> Zvlastna logika.
Ahoj.
Nebudu polemizovat o vyhodach zamku versus MGA ale s Tvym tvrzenim, ze
firmy Oracle a M$ by si mohly bez problemu dovolit predelat system
zamykani na system MGA.
Ja tvrdim ze by to ani pri jejich velikosti a financni sile dost dobre
neslo (alespon najednou) predevsim z duvodu ZPETNE KOMPATIBILITY. Jen
blazen by mohl vydat novou verzi tak klicoveho SW jako je SQL databaze,
ktera by zmenenou architekturou nutila stavajici uzivatele ZASADNE
predelat stavajici systemy. A to by IMHO nutne bylo, neb jsem
programoval drive pro IB a ted programuji hlavne pro MSSQL2000 a vim, ze
rozdil je zasadni (a to nejen z pohledu jine immplementace SQL) ale
hlavne v celkove filozofii pristupu. Viz zde mnohokrat diskutovany
obecny problem multiplatformniho programovani kde pokud mne pamet nemyli
je Erik spise odpurcem multiplatformniho pristupu.
Proto mi jiste das za pravdu, ze reakce zakaznika ve chvili, kdy ma vse
prepsat a predelat je vzdy velmi vrtkava a muze Ti ho to velmi lehce
odvest ke konkurenci (kdyz uz by to stejne musel predelavat).
Naopak, pokus o doplneni vlastnosti MGA do MSSQL a Oracle muze (ale
samozrejme to netvrdim) zrovna tak znamenat urcitou pripravu k prechodu
na system, ktery bude plne postaven na MGA (treba za 1-2 roky) a kam
terba pak budou dobastelny zase zamky pro zpetnou kompatibilitu.
Ze dne na den resp. Z verze na verzi si to nemuzou dovolit ani kolosy
tpu M$ a Oracle.
Ludek
Odpovedá: Milan Tomes
19. 10. 2004 14:37
> [mailto:delphi-l-owner@clexpert.cz]On Behalf Of Winsoft
> Sent: Tuesday, October 19, 2004 3:10 PM
>
> > Nebude zbytecne cekat, pokud T2 nebude potvrzena, ale skonci
> > rollbackem. Pak muze klidne svou zmenu zapsat. Ty jsi sice v prikladu
> > rozhodl ze T2 skonci commitem, a T1 tedy musi obdrzet chybu, ale v
> > dobe detekce kolize jeste o vysledku T2 neni rozhodnuto, a cekani by
> > tedy mohlo mit smysl. A i v pripade neuspechu cekani se muze
> > vyplatit, viz vyse o live locku.
>
> prepac, ale zas si to nedospekuloval, zas len komitne jedna
> transakcia, akurat, ze ta druha. Mne komitli obidva.
Netreba dospekulovavat - jak uz P. Cisar psal - v pripade naprosto
irelevantniho prikladu jsou jakekoliv vydedukovane zavery opet irelevantni.
Uved jediny prakticky a realizovany priklad v realnem systemu, ktery funguje
presne takhle.
S pozdravem
Milan Tomes
Odpovedá: Slavomir Skopalik
19. 10. 2004 16:22
Obeznameni s problemem:
1. DB ma velikost cca 2.3 GB
2. Zalohovani probiha tak, ze se neprve vytvori backup DB a pak se
komprimuje zipem.
3. Zalohovani dalsich DB velmi nepriznive ovlivnuje zalohovani "moji"
DB, jelikoz probiha
soucasne (tedy startuje o 2 hodiny drive, ale dobehne nekdy i pul hodiny
po zahajeni "moji"
zalohy).
4. Cely je to realizovano na RAID5 s 4 disky (paty je hot spare).
5. OS Windows 2000
6. FB 1.0.3
Problemem je opravdu vytrashovani cache, jelikoz aktivni DB spojeni
(ktere nebyla
v testu simulovana!) vytvareji pozadavky na mahodny pristup.
Tim, dochazi k problemem disku.
Vhledem k FB 1.0 neni mozne pouzit FW OFF (jako na linuxu).
Reseni jsem psal.
Dale je treba mit na pameti, ze behem casu dochazi k fragmentaci DB
souboru
a tim i k zpomaleni sekvencniho cteni, zaroven dochazi k fragmentaci
uvnitr
DB souboru.
Aktivita klientu vyrazne ovlivnuje dobu zalohy (problem RAID5 a
zalohovani na stejny disk)
a zaroven zalohovani podstatne ovlivnuje klienty.
Problem je resitelny ( a snadno). Napriklad upgrade na kernel 2.6 + XFS
filesystem + FB 1.5 +
rodeleni pole na sytem a data + pipe + zamezeni soubeznemu spousteni
zalohovani + pridani
USB disku pro backup soubory + .....
Slavek
> Asi to sem nepatri a nehodlam se k tomu nijak siroce
> vyjadrovat. Jen bych te rad upozornil, ze tebou navrhovana
> reseni uz jsme diskutovali a nebylo to uplne, tak jak tvrdis,
> napr. v dokumentaci jsem nasel, ze "pipe" funguji v FB1.0
> pouze na linuxu. Dale je zvlastni ze do provedeni tvych uprav
> bezelo zalohovani i na Windows 30 min. Samozrejme nevylucuji,
> ze jsme neudelali chybu. Jen je zvlastni, ze zalohovani DB
> dalsich firem probiha celkem bez problemu a blbne jen ta tvoje.
>
> Stepan
Odpovedá: Marek Dostal
20. 10. 2004 7:59
> To vsetko sa riesi za chodu systemu za plnej prevadzky? Aky je to podnik,
> ze sa tam pracuje aj v nedelu a cez sviatky s informacnym systemom?
Treba hotely, kde je recepce v provozu 24 hodin, coz je vetsina. Prubezne
zalohovani za chodu pomoci nastroje gbak neni problem.
Marek Dostal
D7Prof, WinXP Home, FireBird 1.0.2
Odpovedá: Ing. Miroslav Vopalecky
20. 10. 2004 9:00
Ahoj.
Kdesi jsem cetl, ze pripona GDB je take jeste nekde pouzivana systemem
Windows. Resenim u toho bylo prejmenovat priponu databaze na fdb. Myslim si,
ze Windowsi si soubory s GDB sleduji pro sebe a neco s nimi delaji.
S pozdravem Mirek Vopalecky, D7 W2000
|Subject: Re: Firebird a GBAK na velkou GDB
|
|
|Obeznameni s problemem:
|1. DB ma velikost cca 2.3 GB
|2. Zalohovani probiha tak, ze se neprve vytvori backup DB a
|pak se komprimuje zipem. 3. Zalohovani dalsich DB velmi
|nepriznive ovlivnuje zalohovani "moji" DB, jelikoz probiha
|soucasne (tedy startuje o 2 hodiny drive, ale dobehne nekdy i
|pul hodiny po zahajeni "moji" zalohy). 4. Cely je to
|realizovano na RAID5 s 4 disky (paty je hot spare). 5. OS
|Windows 2000 6. FB 1.0.3
|
|Problemem je opravdu vytrashovani cache, jelikoz aktivni DB
|spojeni (ktere nebyla v testu simulovana!) vytvareji pozadavky
|na mahodny pristup. Tim, dochazi k problemem disku. Vhledem k
|FB 1.0 neni mozne pouzit FW OFF (jako na linuxu). Reseni jsem
|psal. Dale je treba mit na pameti, ze behem casu dochazi k
|fragmentaci DB souboru a tim i k zpomaleni sekvencniho cteni,
|zaroven dochazi k fragmentaci uvnitr DB souboru. Aktivita
|klientu vyrazne ovlivnuje dobu zalohy (problem RAID5 a
|zalohovani na stejny disk) a zaroven zalohovani podstatne
|ovlivnuje klienty. Problem je resitelny ( a snadno). Napriklad
|upgrade na kernel 2.6 + XFS filesystem + FB 1.5 + rodeleni
|pole na sytem a data + pipe + zamezeni soubeznemu spousteni
|zalohovani + pridani USB disku pro backup soubory + .....
|
| Slavek
Odpovedá: Tomas Bradle
20. 10. 2004 20:36
To rozhodne Win XP delaji 
Je potreba vypnout nastroj obnoveni systemu (tento pocitac | vlastnosti),
jinak pri kazde zmene DB provadi zalohu.
Tomas Bradle
t.bradle@worldonline.cz
----- Original Message -----
From: "Ing. Miroslav Vopalecky" <m.vopalecky@tiscali.cz>
To: <delphi-l@clexpert.cz>
Sent: Wednesday, October 20, 2004 9:53 AM
Subject: Re: Firebird a GBAK na velkou GDB
> Ahoj.
> Kdesi jsem cetl, ze pripona GDB je take jeste nekde pouzivana systemem
> Windows. Resenim u toho bylo prejmenovat priponu databaze na fdb. Myslim
si,
> ze Windowsi si soubory s GDB sleduji pro sebe a neco s nimi delaji.
> S pozdravem Mirek Vopalecky, D7 W2000
>
>
>